Datasheet

ASP.NET reserves the path segment immediately after the application’s virtual root as the location on the

URL where cookieless tickets are stored. In this example, the application was called

inproc, so the next

path segment is where ASP.NET stored the cookieless tickets. All cookieless tickets are stored within an

outer pair of parentheses. Within these, there can be a number of cookieless tickets, each starting with a

single letter indicating the feature that consumes the ticket, followed by a pair of parentheses that contain

the cookieless ticket. Currently, the following three identifiers are used:

❑ S — Cookieless ticket for session state

❑ A — Cookieless ticket for anonymous identification

❑ F — Cookieless ticket for forms authentication

However, the ASP.NET filter does not actually understand any of these three indentifiers. Instead, the

filter searches for the character sequences described earlier. Each time it finds such a character sequence,

it removes the cookieless ticket, the feature identifier and the containing parentheses from the URL and

internally builds up a string that represents the set of cookieless tickets that it found. The end result is

that all cookieless tickets are removed from the URL before IIS attempts to convert the URL into a physi-

cal path on disk. Therefore, IIS doesn’t return a 404 error even though there clearly is no directory on

disk that starts with

(S).

After the filter removes the tickets from the URL, it still needs some way to pass the information on to

the ASP.NET runtime. This is accomplished by setting a custom HTTP header called

ASPFILTERSES-

SIONID

. The name is somewhat misleading because it is a holdover from ASP.NET 1.1 when the only

cookieless ticket that was supported (excluding mobile controls and the cookieless forms authentication

support that was part of the mobile controls) was for session state. With ASP.NET 2.0, though, there are

obviously a few more cookieless features integrated into the product. Because the underlying logic

already existed in the ISAPI filter, the old header name was simply retained.

You can actually see the effect of this header manipulation if you dump the raw server variables associated

with an ASP.NET request. As an example, for an application that uses both cookieless session state and

cookieless forms authentication, the URL after login may look as follows:

http://localhost/inproc/(S(sfeisy55occclkmlkcwtjz55)F(jbZ....guo1))/Default.aspx

For brevity the majority of the forms authentication ticket has been removed. However, the example

shows cookieless tickets for session state and forms authentication in the URL. If you were to dump out

the server variables on a page, you would see the following header:

HTTP_ASPFILTERSESSIONID=S(sfeisy55occclkmlkcwtjz55)F(jbZ....guo1)

Hopefully, this sample makes it clearer how the unmanaged ISAPI ASP.NET filter transfers cookieless tickets

over to the ASP.NET runtime. Within the ASP.NET runtime, the HTTP modules that depend on these tickets

have special logic that explicitly looks for this HTTP header and parses out the ticket information for further

processing (for example, setting up the session, validating forms authentication credentials, and so on).

Initial Phases of a Web Request

04_596985 ch01.qxp 12/14/05 7:46 PM Page 7