- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 27 Jul 1995 05:53:03 +0200 (MET DST)
- 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 UTC