The community is working on translating this tutorial into Georgian, but it seems that no one has started the translation process for this article yet. If you can help us, then please click "More info".
If you are fluent in Georgian, then please help us - just point to any untranslated element (highlighted with a yellow left border - remember that images should have their titles translated as well!) inside the article and click the translation button to get started. Or have a look at the current translation status for the Georgian language.
If you see a translation that you think looks wrong, then please consult the original article to make sure and then use the vote button to let us know about it.
Please help us by translating the following metadata for the article/chapter, if they are not already translated.
If you are not satisfied with the translation of a specific metadata item, you may vote it down - when it reaches a certain negative threshold, it will be removed. Please only submit an altered translation of a metadata item if you have good reasons to do so!
Back in the old days, where PHP and ASP ruled the world, dealing with stuff like the query string happened all the time! You would constantly take input from the URL, through the query string, and return content based on it. A lot of this work has been abstracted by the ASP.NET MVC framework - for instance, parameters from the query string are automatically turned into type-safe parameters on your Controller actions and information posted back through FORM's can be automatically turned into Model objects.
However, you will likely soon run into situations where you need to go a bit more low-level and be closer to the HTTP pipeline. This is relevant whenever you want to access the query string or FORM information directly, but also when you need to deal with stuff like cookies/sessions and response headers. ASP.NET MVC makes it easy for you to access all HTTP related functionality by gathering it all in the HttpContext class.
Accessing the HttpContext
The HttpContext class can be accessed from all of your Controllers. For convenience, you can access HttpContext from a property found on your Controllers called HttpContext. For even greater convenience, some of the properties found on the HttpContext class is also exposed as properties on the Controller, e.g. the Request property.
Accessing the HttpContext from anywhere else than in your Controllers is not generally recommended. It was easy to accomplish in earlier versions of the ASP.NET MVC framework, using the HttpContext.Current property, but it was removed in ASP.NET Core, because it basically violates some of the core principles of the MVC architecture. However, if you really need to do it, e.g. to support legacy code, there are ways around it - I suggest that you have a look at this StackOverflow thread for more information.
There's a LOT of properties and methods relating to the HTTP pipeline, so for convenience, the members of the HttpContext class has been split into several objects, which you can access as properties on the class. Here's a list of the ones you'll likely be using the most:
- HttpContext.Request - all members related to the current request, e.g. the QueryString, Forms and so on.
- HttpContext.Response - all members related to the Response about to be delivered, e.g. Cookies and response headers
- HttpContext.Session - all members related to dealing with Session (generally used to persist data between requests)
- HttpContext.User - all members related to dealing with a (potentially) authenticated user
In the upcoming articles, we'll dig deeper into each of these objects and talk about the most important functionality found in them.
The HttpContext class allows you to get a lot closer to the HTTP pipeline and deal with more low-level stuff your self, e.g. the QueryString and Cookies.