W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Session-id and proxies (was: Re: session-id redux)

From: Darren New <dnew@sgf.fv.com>
Date: Wed, 26 Jul 1995 17:22:04 +0100
To: Koen Holtman <koen@win.tue.nl>
Cc: "Daniel W. Connolly" <connolly@beach.w3.org>, koen@win.tue.nl, brian@organic.com, www-talk@www10.w3.org
Message-Id: <Pine.3.89.9507261717.C3057-0100000@sgf.fv.com>
> Another way to disable caching is for the service author to put a
> Expires: <yesterday> headers in the response.  Thus, we get the
> following proxy requirements:
> 
> - the proxy must of course not cache beyond the expires date
>   (I hear some braindead system managers configure their proxies
>    to cache even expired stuff for a small amount of time, contrary
>    to what the spec says.)

But you see, this is a real and true problem, and not something you can 
shrug off.  Let's say you're selling hot stock quotes; do you really 
want everyone at TLA Corp to get it just because TLA Corp bought a broken 
proxy server? What happens when someone buys today's Dilbert strip and 
they get the same one they saw yesterday.  Guess who has to deal with 
that customer.  It ain't TLA's MIS department.  And upgrades?  We can't 
even get everyone to implement the "user-agent" tag properly.

What happens when that customer orders something today that they ordered 
yesterday, cause it's such a good deal, and the proxy returns yesterday's 
"It's on the way" message and you, the vendor, never even heard the request?
A solution that works only when everything goes well isn't going to fly 
on the Internet. ;-)

> Clearly, in terms of bandwidth, session-id-in-the-url is a very costly
> solution to the statefull dialog problem.

True, if that's how you do it.  It's not necessarily the only way to do 
it, tho.
   --Darren
Received on Wednesday, 26 July 1995 17:29:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT