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

> 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 UTC