Re: making progress on State-Info

M. Hedlund:
>
>Imagine an extended newspaper archive search done through a Web browser.
>Say the archive-server would like to avoid showing you articles you have
>already reviewed; and say the server stores articles by week.  As you read
>an article, the server responds with a state-info header that says "within
>path /week1, send state-info token w1a1."  The browser flits around the
>archive and returns to /week1.  Rather than having to send one token for
>every article reviewed (w1a1, w3a4, w5a7 ....), it just returns the
>token(s) for week1.  The server modifies the week's index accordingly.

Thanks for the example, in this case, having `path=' indeed saves you
from building a server side database.

I believe my remark on `path=' at the time had to do with the `large
shopping bag problem'.  In a tele shopping application, you could, by
using `path=', divide the shopping bag into multiple sections, each
one holding products from a different part of the shop.  But a request
on the `cash register' or `I want to order and pay for the contents of
my basket' URL would have to have contain the shopping bag information
from all bag sections at once, which may lead to a Cookie request
header large enough to overrun a buffer in client, server, or proxy.

So for shopping applications, `path=' doesn't buy you that much.
Beyond a certain bag size, you will either have to give a `your bag is
too full to hold any more products' message, or switch to a backup
scheme that stores the bag contents a server side database and uses
the cookie header to hold the database key.

>The advantage is that you can maintain several state-registers particular
>to parts of (or the whole) server without returning a full session history
>with each request; the token-database is client-side.  The disadvantage is
>that you blow away Dave's provision for an unspecified header-content.

I don't quite see what you mean here.  The NAME=VALUE pairs which
carry the actual state in the cookie headers are just as opaque as the
state information in Dave's state-info header would be.

>  A
>side effect would be the need to return more than one state-info token in
>the same request.

Yes.  In general, compared to state-info, Netscape cookies put greater
complexity at the browser side.  With cookies, it is the browser that
has to keep the state for different applications on the same server
apart: with state-info, the complexity is at the server end.

>I'm not saying this is optimal -- I'm happy with Dave's proposal as it
>stands.  I am suggesting a potential middle ground.

I don't think that `path=' is that controversial a feature: it is one
of the few parts where privacy problems are almost absent.  If browser
authors express that they are willing to implement the associated
complexity, I see no reason for not putting it in the proposed
standard.

>M. Hedlund <hedlund@best.com>

Koen.

Received on Sunday, 10 December 1995 13:19:20 UTC