Actually, I'm arguing that I've always had more success making things
work in a diverse environment by relying only on the stuff that has to
work right for simple things to work, rather than counting on everyone to
get the hard stuff right.
Kind of like using K&R C instead of ANSI until enough compilers get out
there that you can justify saying "You need an ANSI compiler." (My boss
still doesn't think we're there yet. :-)
> I like to argue that non-spec-conforming caches are bad because they
> make the implementation of statefull dialogs hard.
Definitely.
> 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.
Yes, it's a shame how that works, but that's how it works. The other
choice is to minimize the amount of statefulness to the minimum
necessary, at which point the fact that the cache (broken or not) isn't
caching Albert's pages and giving them to Betty is the right thing.
I don't see how if I pick 12 things out of a catalog before I submit the
purchase and Jane picks a different 8, how my page can be cached and
served to Jane. Now, the inline GIFs, yes, but you don't need to modify
the URLs for them. If you have Java or SafeTcl or something like that
running locally, again yes. But I don't see what the session-id header
buys you that the URL mung doesn't except that you don't have to edit
HTML on the fly at the server. Editting URLs on the fly at the server
gives you the benefit of working with non-conformant caches and older
clients.
> 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.
You know, email's pretty old, and it's still broken. AOL's GET forms were
broken for a while (now fixed, due to excellent customer support on their
end :-). NetCruiser's form handling is still broken. Compuserve and
Prodigy still bounce email to the wrong addresses. Heck, NetCruiser's
*telnet* is broken, and telnet was one of the first applications ever
written on the internet, and telnet really isn't that hard.
The internet is growing fast enough that the software isn't likely to be
stable any time soon. You'll always have to deal with software that
doesn't work in the details. Win'95's cache is likely to be broken, MS's
email gateway for Japan doesn't conform to the latest RFC's, and I would
bet NT's proxy isn't going to get every detail right on the first release.
> 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.
True, but only the responsive ones, and only if there's a standard folks
can point to. And only if you're willing to write off those potential
customers behind broken caches.
> 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.
Definitely. That means now only 30% of your customers come back to your
customer service department. ;-)
> However, the http spec supports you in blaming the MIS department.
It would be nice if it were that easy. You can't really say "Sorry, but
we're not going to refund your money because your MIS department is
running six-month-old web software."
====
Don't misunderstand. I'm not trying to derail things. I'm just trying
to play devil's advocate so everyone involved considers the points in
their entirety. Mung'ed URLs aren't going to go away as long as 30% of
the browsers *don't* implement expires: properly. And as far as I can
tell, there isn't even consensus on how to implement expires: for the
history list, so I'm not sure how you can say "expires works" for 70% of
the browsers. I'm pretty sure that most browsers don't expire documents
during the same session, so even now it's not clear to me that "expires
works" at all.
--Darren