Simulating Cookies with the Cookie Munger

Microsoft Corporation

October 10, 1997

[Editor's note: We are providing the Cookie Munger on this site in early May 1999.] Download the Cookie Munger filter.

Contents
Introduction
How Cookie Munger Works
Things to Think About When Using Cookie Munger
If You Don't Want to Use Cookie Munger
A Caveat
For More Information

Introduction

In the fast-paced world of Web development, developers who use Active Server Pages (ASP) and session-state methods can easily overlook the fact that not every browser supports cookies. To work around this problem, Microsoft has released the beta version of Cookie Munger. Cookie Munger is an Internet Server Application Programming Interface (ISAPI) filter that munges both the outgoing HTML and incoming HTTP transactions to simulate cookies and maintain session state (or other information stored in cookie text files).

Cookies are a feature of HTML 2.0 and are used by Web developers to enable their sites to save variables or named pieces of information directly on the user's computer. When the user revisits the site, the cookie is sent along, enabling the site to restore variables and state information from the previous session.

Although cookies are an accepted method of tracking of a visitor's session state, many older browsers cannot accept cookies because they pre-date the HTML 2.0 standard (they also lack the ability to parse tables and frames, but that's another story). Web designers aiming for the widest audience possible, however, don't want to leave those browsers out in the cold.

Other users may have disabled their browsers from processing cookies due to privacy concerns. They prefer anonymity, and think that cookies leave a trail of crumbs -- showing where they've been and what their interests are -- on the servers they've visited. (While ASP mostly uses just one cookie, ASPSESSIONID, to maintain session state, ASP application-builders can use additional cookie capabilities to track visitor preferences.)

Still other users have configured their browsers to warn them of incoming cookies, and get very annoyed by the barrage of cookies sent by sites that use ASP. For example, a lot of cookies get sent to a user if there's no GLOBAL.ASA file associated with an ASP application, and a few get sent even when there is. (Nancy Winnick Cluts tells you all about GLOBAL.ASA files and other ASP performance tips in 15 ASP Tips to Improve Performance and Style.)

To effectively use ASP, however, some kind of cookie-ish functionality is necessary. ASP expects a browser to send the ASPSESSIONID cookie with every request it makes. Without it, ASP does not know which session the user owns, and cannot keep the Session object up-to-date as the user moves from page to page. (For a whole article devoted to cookies and session state, check out Michael Levy's ASP and Web Session Management article.) The Cookie Munger filter extends the power and functionality of ASP to users whose browsers cannot or will not accept cookies.

How Cookie Munger Works

The Cookie Munger filter is a utility that enables Active Server Pages to work with browsers that do not support or refuse to accept cookies. The Cookie Munger filter intercepts server requests before they are screened by the ASP filter. Once a request is captured, the filter processes it to determine if the browser is accepting cookies. The process is described as follows:

The server receives a request for a particular URL. Cookie Munger intercepts the request before it is passed to ASP. If the headers of the request contain a "Cookie: ASPSESSIONID=xxx" header (in other words, the browser accepts cookies), then the ASPSESSIONID variable is sent on to ASP to be processed normally. If the URL contains an encoded ASPSESSIONID (a URL that the Cookie Munger filter has added cookie-ish information to), the ASPSESSIONID is removed from the URL, Cookie Munger generates a Cookie header for ASP, and forwards the request.
When ASP sends out a page in response to a request, Cookie Munger intercepts the page before it leaves the server. If Cookie Munger knows the browser accepts cookies, it does nothing. If Cookie Munger instead knows the browser does not accept cookies, it will remove any Set-Cookie headers and munge ASPSESSIONID information onto the end of any local URLs embedded in the page (for example, the URL http://foo/bar.asp will be appended to look something like http://foo/bar.asp-ASP=PVZQGHUMEAYAHMFV).
If the user clicks on one of the modified URLs returned by Cookie Munger, the request comes back to the server, Cookie Munger reconstructs a new ASPSESSIONID header, passes the request on to ASP, and so on.

Things to Think About When Using Cookie Munger

Filtering outgoing raw data is an expensive process. Every byte of data sent out by IIS must be streamed through the filter. There are unavoidable performance costs associated with IIS copying all data from kernel to user memory.
It is impossible to give an accurate prediction of how much performance will degrade on your server with Cookie Munger installed. On a lightly loaded server, the difference should not matter. On a heavily loaded server, the performance might degrade to an unacceptable level.
This filter will work in most cases, but it's not a cure-all. It's a compromise, but a good compromise that still enables you to use the power of ASP with cookie-free browsers. This filter is transparent to Active Server Pages; ASP does not know that the filter is present.
Cookie Munger is an "all-or-nothing" process. There is no reliable, nonintrusive method to detect whether a browser will accept cookies. Nor is it possible to configure the filter on a per-user basis (administering a database for a large site with hundreds of thousands of visitors would be prohibitively time-consuming anyway). If the filter is installed, it filters all outgoing ASP pages.
URLs will look complex (http:/foo/bar.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, the URL will be unreachable.
Only local URLs are modified. Absolute URLs (http://www.microsoft.com/test/test.asp) and local-absolute URLs (http:/test/test.asp) are not modified. (It is good HTML style to use relative URLs wherever possible; they ensure location independence, and moving a set of pages to a different server or directory will not require modifying the text.)
Cookie Munger does not work well with pure HTML pages (files with an .HTM or .HTML extension), because they will not send Set-Cookie headers. On those occasions, Cookie Munger has no way of knowing whether or 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 (for example, http://www.sportszone.com to http://espn.sportszone.com), Cookie Munger will not modify them.
Cookie Munger eats all outgoing cookies. If some other CGI or ISAPI application is sending Set-Cookie headers, those cookies will never reach the users' browsers. You will have to modify CkyMunge yourself to not eat cookies sent by these applications.

If You Don't Want to Use Cookie Munger

If you elect to not use Cookie Munger, you can minimize the number of cookies sent by Active Server Pages in one of two ways:

Insert something into the Session object. For example:

      <% Session("something") = whatever %>

Insert a GLOBAL.ASA into the virtual root for your application, with an empty Session_OnStart subroutine. (See the Nancy Winnick Cluts article on ASP performance tips for more detail.)

A Caveat

The beta version of Cookie Munger is not officially supported by Microsoft Corporation. Peer support is available on the Active Server Pages mailing list or on the microsoft.public.inetserver.iis.activeserverpages newsgroup.

For More Information

To subscribe to the Active Server Pages mailing list, send mail to listserv@listserv.msn. com with

subscribe ActiveServerPages [firstname lastname]

in the body of the message, and follow the directions carefully. (firstname and lastname are optional.)

You can reach the newsgroup through msnews.microsoft.com and other NNTP servers.