Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about the realization of non-Cookie conversation. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

No Cookie session

In ASP.NET, you can selectively establish the necessary session-user contact without using Cookie. Interestingly, you don't need to change anything in your ASP.NET application to enable Cookie-free sessions except for the following configuration settings.

The default settings for ASP.NET session state are defined in the machine.config file and can be overridden in the web.config file in the root folder of the application. You can enable no Cookie sessions by ensuring that the above lines appear in the root web.config file. That's it-simple and effective!

Nodes can also be used to configure other aspects of session state management, including storage media and connection strings. However, in the case of Cookie, you only need to set the cookieless property to true (the default is false).

Note that the session settings are application-wide settings. In other words, all the pages in your site will either use or will not use Cookie to store the session ID.

Where does ASP.NET store the session ID when not using Cookie? In this case, the session ID is inserted into a specific location within the URL. The following figure shows a snapshot of a real site using no Cookie sessions.

Figure 1. Use MapPoint without Cookie session

Suppose you request a page similar to http://yourserver/folder/default.aspx. As you can see from the MapPoint snapshot, the adjacent slash in front of the resource name is expanded to include parentheses populated with the session ID, as shown below.

Http://yourserver/folder/(session ID here) / default.aspx

The session ID is embedded in the URL and does not need to be persisted anywhere else. Well, that's not exactly the case. Please consider the following options.

You visited a page and were assigned a session ID. Next, you clear the address bar for the same browser example, go to another application, and get started. Then you retype the URL of the previous application and (guess what) retrieve the session value as you enter.

If you use a Cookie-free session, the second time you access the application, you will be assigned a different session ID and lose all previous states. This is a typical side effect of non-Cookie sessions. To understand why, let's further explore the implementation of a Cookie-free session.

Implementation of non-Cookie conversation

The implementation of a Cookie-free session benefits from the efforts of two runtime modules: a standard session HTTP module called SessionStateModule, and an executable file named aspnet_filter.dll. The latter is a small piece of Win32 code that acts as an ISAPI filter. The HTTP module and the ISAPI filter implement the same idea, except that the HTTP module consists of managed code and requires ASP.NET and CLR triggers to work. Traditional ISAPI filters such as aspnet_filter.dll are invoked by Internet Information Services (IIS). Both intercept IIS events that are fired during request processing.

When the first request of a new browser session comes in, the session state module reads the settings about Cookie support in the web.config file. If the cookieless property of the section is set to true, the module generates a new session ID, splits the URL by populating the session ID to the adjacent location before the resource name, and uses the HTTP 302 command to redirect the browser to the new URL.

When each request reaches the IIS entry (long before it is handed over to ASP.NET), aspnet_filter.dll gets a chance to view it. If the URL embeds the session ID in parentheses, the session ID is extracted and copied into a request header named AspFilterSessionId. Then, rewrite the URL to make it look like the originally requested resource and release it. This time, the ASP.NET session state module retrieves the session ID from the request header and continues to work through the session-state binding.

As long as the URL contains information that can be used to get the session ID, it works well without the Cookie mechanism. However, this will cause some usage restrictions.

This is how the implementation of the non-Cookie session shared by the editor is like. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.