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.