Statefulness (was ...URL...)

Shel Kaphan (sjk@amazon.com)
Fri, 1 Dec 1995 13:39:30 -0800


Dave Ladd writes:
> >> allowing for state information to be held in the URL.
> >That has no effect on the existance of state information in a URL
> >(which, BTW, is always the wrong solution to a stateful session).
>
> In the current world, what other options are there for stateful sessions?
> - hidden fields? (loses for HREFS)
> - per-remote-host state? (works until aol.com is the remote host)
> - magic cookies? (non-standard, but common)
>
> I like Kristol's proposal, but without that, messing with the URL seems like the only way to go--- it's certainly not "always wrong".
>

There is a subtle distinction between "messing with the URL" and with
encoding state on a page in URLs, hidden fields, or some other
mechanism. The subtle distinction is that "messing with URLs" can
provide a way to pass around tokens identifying server-side state,
whereas including state on the page itself is indeed not a good
solution, because if a user uses a browser's history mechanism
(e.g. "BACK") to go to previous pages they will be throwing away the
accumulated state since having visited that page.

The problems with URL munging are that (a) it prevents adequate
caching of the pages, since the URLs (and page contents if any links
are present) are different for each user, and (b) it is comparatively
expensive to generate pages where all the links are munged.

(a) above is actually sometimes an advantage given the complex (and
grommy) interaction of browser history mechanisms, caches in browsers
and proxies, and varying interpretations of and levels of compliance
with the specs for Expires and Cache-control headers and Pragmas.

Deferring this problem with some claim that new media types should be
invented to handle this is academic (in the pejorative sense) and
impractical. Servers that provide stateful services have no choice but
to use a mechanism that will work across the board with all the
browser types they wish to support.

Both Dave Kristol's proposal and the Netscape cookie mechanism would
solve the problem, but only if they were widely adopted. The working
group should really get its act together and endorse some proposal
that addresses this problem.

Shel Kaphan