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

Darren New (
Wed, 26 Jul 1995 17:22:04 +0100

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