Table of Contents 
Previous Section
State in Cookies
A "cookie" is another way that a web application can store state information on the client machine. Instead of being part of the HTML page as with the state-in-the-page mechanism, a cookie is passed as part of the HTTP header information. Here is the syntax for the cookie header line:
Set-Cookie: NAME=VALUE; expires=DATE; domain=DOMAIN_NAME; path=PATH; secureThe NAME=VALUE association is the only required field. It holds the cookie's data and the name by which it can be accessed. The other fields are optional and set limitations on when the data will be passed from the client back to the server, as shown in the following table:
See http://www.netscape.com/newsref/std/cookie_spec.html for a complete description of cookies.
//Java Application.java
public Application() {
super();
setSessionStore(SessionStore.cookieSessionStoreWithDistributionDomain("", false));
}
//WebScript Application.wos
- init {
[super init];
[self setSessionStore:
[WOSessionStore cookieSessionStoreWithDomain:@""
secure:NO]];
return self;
}
In this example, we set the domain to the empty string so that cookies that this application sends to the user are valid for all domains. We also turn off the requirement for a secure communications channel. Note that the cookie store API doesn't allow for a path argument. WebObjects automatically restricts the path so that cookies that an application produces are valid only within the application directory. For example, if you set the SessionStores application to use a cookie session store, the client returns a cookie only if the request URLs have this prefix:
/cgi-bin/WebObjects/Examples/SessionStores.woa/As with storing state in the page, the cookie session-storage mechanism uses archive objects that should be stored. WebObjects packages the session state by archiving the session object (and all the component objects that it contains) into an NSData (next.util.ImmutableBytes) object. The NSData object is then asked for its ASCII representation. WebObjects pairs this data with names it generates and creates the Set-Cookie headers of the response page.
The process is reversed when a user submits a request containing cookies. The ASCII archive from the Set-Cookie headers is converted to its binary, NSData, representation. The session object and the components it contains are then unarchived from the NSData object, thus restoring the session state.
One of the big advantages of using cookies over state in the page is that you don't have to design your application around forms. As you recall, storing state in the page implies using hidden field elements, which must be located in HTML forms. Cookies, however, are stored in the HTTP header and so are independent of the HTML elements in the page. With a cookie session store you could, for example, let users navigate from page to page by using hyperlinks rather than by submitting forms. In addition (and for similar reasons), storing state in cookies works better with frames than does storing state in the page.
However, the cookie mechanism has a size restriction that limits its usefulness. Currently, cookie data is passed from the HTTP server to the WebObjects application either through environment variables that typically are limited to 4KB or through a server's own API that in some cases is even more restrictive. We recommend that cookie state data (that is the ASCII representation of the state data) be kept to 2KB or less. Given these limitations, cookies can be best used for such things as storing keys used to fetch information from a database.
Table of Contents 
Next Section