Using Cookieless Sessions

When you create a mobile Web project in Microsoft Visual Studio .NET, a web.config file is created as part of the project. In this configuration file, several default settings are established for the application. One of these enables cookieless sessions. (Another configuration setting defines a set of device filters, which we’ll talk about more in the “Using Device Specific Filters” section later in this chapter.)

Cookies are passed between client and server as part of the request headers. Some mobile devices don’t have the logic for managing cookies, and others allow the user to turn cookie use off. Normally, server sessions will not work correctly without cookies and desktop developers can treat session support as optional. In fact, to reduce use of server resources, some applications will explicitly disable server session state. Server sessions are particularly important in mobile pages because mobile pages use session state to assist in managing the view state. On regular desktop pages, the view state is passed between the client and server on each request, allowing for state to be simulated in an otherwise stateless protocol. Mobile pages minimize the amount of data that must be passed on each request and use up part of the limited browser memory by storing some view state in session. Without cookies, a new session is created on each request because the session identifier is not sent, and view state will not work correctly. In cookieless sessions, the session identifier is carried as part of the URL so that a server session exists for the user without the use of client-side cookies. When a request is first received without a session identifier as part of the request path /samplePath/somePage.aspx, the browser is redirected to the same page with a modified URL carrying a session identifier. /(sessionIdentifier)/samplePath/somePage.aspx. For the duration of the session, the session identifier is implied by relative requests, or added to fully qualified paths to keep the user connected to the current session.

To turn on cookieless sessions, include a cookieless=“true” direction in the sessionState section of your web.config file. The web.config file in Listing 4-2 is simplified to include that direction.

Code Listing 4-2: Cookieless Web.config

 <configuration>
    <system.web>
        <sessionState cookieless="true" />
    </system.web>
</configuration> 

Tip

Use cookieless sessions to ensure that your application works correctly on devices that do not support cookies.

Some browsers without built-in support for cookies still appear to work correctly when receiving and returning cookies. Prior to WAP 2, WAP browsers could not initiate HTTP requests directly to the Web server. Instead, they connected to a WAP Gateway, which acted as a proxy for them. The gateway translates the WAP request from the browser into an HTTP request. Figure 4-3 shows this process.

Figure 4-3: The gateway translating a WAP request from the browser

Some gateways offer additional functionality by tracking the cookies on behalf of the device. The browser never actually sees the cookie, but to the server, the browser appears to support cookies. Because this is a function of the gateway and not the browser, don’t be surprised when you examine the browser capabilities and find that support for cookies is set to false, even though the tracking appears to work some of the time. Don’t assume you know the capabilities of the general device and ignore the possible impact of the gateway.