Using the Cookie Munger Filter

Using Cookie Munger

Cookie Munger works as follows:

The filter receives a request for a particular URL. If the headers of the request contain a "Cookie: ASPSESSIONIDxxxxxxxx=xxx" header, then that ASPSESSIONID is recorded. If the URL contains an encoded ASPSESSIONID (see step 2), the ASPSESSIONID is removed from the URL and a Cookie header is generated instead. The ASPSESSIONID, if present, is recorded for this transaction.
Cookie Munger filters all outgoing data. When ASP sends out a page in response to the above request, Cookie Munger removes Set-Cookie headers with ASPSESSIONIDs, if present (to eliminate cookie warnings in browsers that do not support them), and "munges" any local, relative URLs embedded in the page (for example, http:microsoft/web.asp may become something similar to http:microsoft/web.asp-ASP=PVZQGHUMEAYAHMFV).
If the user clicks on one of those modified URLs, the request comes back to the server (and filter) and step 1 starts over again.

Notes

Filtering outgoing raw data is an expensive process. Every byte of data sent out by IIS must be streamed through the filter. The filter goes to some pains to be smart about not unnecessarily processing data it's not interested in (such as GIFs), but there are unavoidable performance costs associated with IIS needing to copy all data from kernel memory to user memory.

It is impossible to give an accurate prediction of how much performance will degrade on your server if the Cookie Munger filter is installed. On a lightly loaded server, the difference should not matter. On a heavily loaded server, the performance might become unacceptable.

It is recommended that you measure the performance of your server both with and without the filter installed and see if the convenience of supporting users who won't accept cookies or users with old browsers outweighs the cost of poorer performance. User education might be a better solution in the long run.

If you elect not to install this filter, you can minimize the number of cookies sent by Active Server Pages in one of two ways:

Put something into the Session object. For example: <% Session("something") = whatever %>
Put a global.asa into the virtual root for your application, with an empty Session_OnStart subroutine.

In IIS 5.0, you can turn off session state (and hence cookies) entirely:

On an individual page, place
```
  <% @ EnableSessionState=FALSE %%>
```
at the top of the page.
For an entire ASP application: Start the Internet Service Manager, select the Web site that you want to disable session state for, and open its Properties sheet. On the Directory tab, select Configuration. On the App Options tab, clear Enable Session State.

The filter has three modes: Off, On, and Smart. In Off mode the filter does no work (a better way of turning it off is to remove it from the list of filters). In On mode, all URLs will be munged as normal and no cookies will be sent out. In Smart mode, the filter will munge text and let cookies go out to the browser. If the cookie comes back, it will stop munging URLs and use the cookies. If the cookie doesn't come back, it will begin eating outgoing cookies and continue to munge URLs. This will result in slightly better performance. The mode is controlled by a registry setting:

          HKEY_LOCAL_MACHINE\SYSTEM\
              Software\
                  Microsoft\
                      CkyMunge\
                          MungeMode (DWORD)

A value of 0 is Off, 1 is On, and 2 is Smart.

URLs will look unconventional (for example: http:/microsoft/web.asp-ASP=PVZQGHUMEAYAHMFV). Users can still bookmark them, however. If the ASPSESSIONID is stale, the server will assign them a new session ID and start a new session. If Cookie Munger has been disabled in the meantime, then the URL will be unreachable.

Only local URLs are modified. Absolute URLs are not modified (for example, http://www.microsoft.com/test/test.asp), nor are local-absolute URLs (for example, http:/test/test.asp). It is good HTML style to use relative URLs wherever possible, to ensure location independence, so that moving a set of pages to a different server or directory will not require modification of the text.

The filter does not work well with pure HTML pages (pages with an .htm or .html file name extension), as the Set-Cookie header does not get sent out by IIS. Thus, the filter has no way of knowing how to modify any embedded URLs. Rename your .htm and .html pages to have a .asp extension, even if they contain no server-side scripting.

If you have some client-side scripting that dynamically constructs URLs in the user's browser (windows.navigate), these URLs will not be modified to contain the ASPSESSIONID.

This filter is transparent to Active Server Pages. It neither knows nor cares that the filter is present.