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

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

From: Koen Holtman <koen@win.tue.nl>
Date: Thu, 27 Jul 1995 05:53:03 +0200 (MET DST)
Message-Id: <199507270353.FAA08543@wswiop05.win.tue.nl>
To: dnew@sgf.fv.com (Darren New)
Cc: koen@win.tue.nl, connolly@beach.w3.org, brian@organic.com, www-talk@www10.w3.org
Darren New:
>[Koen Holtman:]
>> - 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.

I don't want to shrug off this problem, I've been having lots of
trouble with non-conforming caches (in browsers) myself.  However, I
do think you have your sense of priorities wrong.

You seem to argue (as Brian's FAP seems to argue, see the CON: in
point 3) that statefull dialogs are bad because statefull dialogs are
not supported by non-spec-conforming caches.

I like to argue that non-spec-conforming caches are bad because they
make the implementation of statefull dialogs hard.

Worse, implementations of statefull dialogs that do exist must
currently use one-time-url's and other hacks to prevent caching by
broken caches.  These hacks mostly make correct caching by caches that
*do* work impossible.  Thus, broken caches defeat the whole purpose of
having caches in the first place.

Of course, if a significant number of caches would still be broken 5
years from now, that would be a good reason not to put any (more
direct) support for statefull dialogs into http, and to turn to an
other medium if you want statefullness.  But in fact I think that once
statefull dialogs become more common on the web, this will put
pressure on system managers to make their caches conform.

The internal caches in recent versions of 70% of all popular browsers
now handle the Expires header according to the spec, so there is
definitely a trend to improvement here.

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

However, the http spec supports you in blaming the MIS department.

Anyone with a sufficiently impressive letterhead want to put out a FUD
press release saying that service providers that claim they offer WWW,
but implement it with a broken cache, take a great risk of being sued
by customers of web shops whose transactions went wrong?  I don't know
that much about the US legal system, but this might actually have the
effect of impoving cache conformance.


>   --Darren

Koen.
Received on Wednesday, 26 July 1995 23:53:47 GMT

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