Re: On transparency

Roy T. Fielding writes:
 > > Only "never check" would be non-compliant.  And the state management
 > > subgroup _needs_ it to be non-compliant with HTTP/1.1, because you
 > > can't reliably use cookies to build stateful services under the `never
 > > check' behavior.
 > 
 > It is certainly true that cookies may get messed up when any recipient
 > is in "never check" mode.  However, making "never check" non-compliant
 > would not make cookies any more reliable, because the "never check" mode
 > is more important than HTTP compliance.  The only thing we can do is
 > make it clear to the user when semantic transparency is necessary for
 > correct behavior.
 > 

In the interest of trying to converge before the next millenium, and
without first going into a specific design for a solution, do people
believe this issue would be taken care of if there were a mechanism so
the user could be informed if the application needed "semantic
transparency" to work correctly, and the browser was set up to
override it?  (I'm assuming that by "semantic transparency" we mean
the user cannot detect, except by performance measurements, that
s/he's using a cache at all).  If it had the right properties,
especially a very simple and understandable user interface (yes I know
that's not up to HTTP) I think it might address everyone's worries.

 > > Actually, you _can_ reliably use cookies under the `never check'
 > > behavior, by using various `cache busting' techniques that have a
 > > disastrous impact on the efficiency of all caches.  Anyway, I've said
 > > this many times before.
 > 
 > Assuming the server is still using cache-control, this has no more
 > impact on "all caches" than does using cookies.
 > 
 > > As someone who implements stateful services, I could live with `never
 > > check' being allowed under HTTP/1.1, _but only_ if the user agent
 > > signals this to my server, so that I can give the user an appropriate
 > > warning message:
 > > 
 > >  `Please enable document verification in your browser caching setup,
 > >   as the correct working of this service depends on it'.
 > 
 > So you want something from the client, like max-stale.
	
The problem with this is that if a client holds things in its cache
longer than the server prefers there may be no request coming from the client
at all.  So putting in some directive on all requests indicating the 
client is in "my rules are more important than your rules" mode
sounds like the only thing that will work.

 > 
 > >>Shel is wrong.  The problem is in his own application assuming that
 > >>the user will always want a stateful session.
 > > 
 > > His application can assume that the user wants a stateful session,
 > > because his application is about filling a shopping basket with books,
 > > which is inherently stateful.
 > 
 > No, his application is about selling books; it is only stateful because
 > that is how he wants the user to interact with the site.

We'd love to hear practical alternatives.  (Practical = will work on
99% + of the presently deployed installed base of browsers, without
helper apps).


  It is not true
 > that all possible ways to interact with a site must be equally supported
 > by all users of HTTP.

But it is true that for some applications, with current technology
(including deployment issues), it is very, very difficult if possible
at all to come up with a purely stateless solution.   BTW I don't
accept "solutions" that embed state in the documents themselves.

  A user that doesn't want stateful interaction
 > should be given that choice.
 > 

They have the choice -- of not using that application/site. That may be the
only way they can exercise that choice.


 > > OK, now for a constructive proposal.
 > > 
 > > If you insist that HTTP/1.1 must make it legal for user agents and
 > > proxy caches to ignore a Cache-Control response header, then I insist
 > > that user agents and proxies always warn origin servers about doing so
 > > by including a particular header in every request:
 > 
 > Nope -- it would just be abused by service providers.  Besides, the user
 > may change settings after the request is made.  Why not just send a
 > Warning header in a response to any request containing max-stale?
 > 
You can't send a warning in response to a request you never get.


 > NOTE TO JEFF:
 > 
 >    I do not believe that any change to the name "max-age" is acceptable,
 >    given that it DOES mean the exact same thing on both request and response.

It means *almost* the same thing.  In requests, is applies to the
current request/response.  In responses, it becomes an attribute
of the cached entity and applies to *future* requests.  It means the
same thing on a request to which it applies, but the fact that it
applies to different requests says that it means something different.
I don't mind if both are called "max-age".

	...
 > 
 >  ...Roy T. Fielding
 >     Department of Information & Computer Science    (fielding@ics.uci.edu)
 >     University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
 >     http://www.ics.uci.edu/~fielding/

--Shel

Received on Sunday, 25 February 1996 17:37:11 UTC