This works most of the time... but, there are some nasty limitations.
- the length of a cookie cannot exceed about 2000 bytes.
- firewalls are frequently configured to filter cookies
- browsers can be configured to not accept cookies
Unfortunately, the only reliable way to store state under HTTP is in the URL
or in the HTML page.
If in the URL, you can either push the state directly into the URL (which can
yield some ugly URLs) or have a session/state identifier in the URL.
WebObjects uses a session identifier in the URL, by default.
Alternatively, state can be kept in the HTML pages as a series of hidden form
fields. Unfortunately, this means that every single "stateful" link on the
page must actually be a form submission-- i.e. must be either a form button or
an image. This also means that every round trip to the server will require
all of the state to be sent to and received from the server.
b.bum
Helge Hess wrote:
> Bill Bumgarner wrote:
> >
> > - The web was designed to be inherently stateless... As such, any state
> > you wish to maintain you have to do so yourself. Now, packages like
> > WebObjects do a brilliant job of maintaining per-user state in a passive
> > manner... but the interface to that state is still traditional, passive,
> > HTTP connections. Moving away from that causes problems.
>
> At least there are cookies, so if it's a simple application, like a web
> catalog, you can manage some state via HTTP.
>
> Helge
> --
> MDlink online service center
> http://www.mdlink.de/
