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

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

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

Received on Thursday, 27 July 1995 09:54:22 UTC