Re: Warning: header, need origin

Roy T. Fielding:
>[Koen Holtman:]
>> For the page showing me my shopping basket, however, the server sends
>>   Vary: Cookie
>>   Cache-control: max-age=0
>> in order to get (conditional) GET requests _every time the page is
>> accessed_.  Thus, if I visit my shopping basket page, then put more
>> stuff in my shopping basket (by following links to CGI scripts in
>> product pages), and then re-request to my shopping basket page, the
>> server can send me the updated shopping basket.
>> 
>> So what we don't want is caches which are configured to give stale
>> responses instead of doing a conditional GETs when the max-age is
>> exceeded: this leads to the showing of the old basket, which is
>> unacceptable.
>
>In cases where the Cookie is being used as an authenticator and not
>as a state identifier, the entity should always be marked as
>
>    Cache-control: private
>
>but that is a secondary issue.

You do not always have to include Cache-control: private if the Cookie
is being used as an authenticator.  If the information returned is not
of a private nature (for example if it is a room in a mud or a page in
a collaborative document), there is no sense in disallowing a shared
cache to cache this information.  Not all browsers are configured to
do local caching.  I regularly tell people using NetScape on our sun
cluster to turn of their local disk cache and use the shared proxy
cache, because local disk caching just wastes 10(?) Mb disk space on
each user account for no good reason.

>> This is why to need to detect if you can indeed rely on caches not
>> returning stale responses.
>
>You can't detect this because even a private cache can have its behavior
>altered between requests.

Though I agree that there is no 100% reliable way to detect
opaqueness, my proposed detection mechanism is a huge improvement over
no detection.  It is good enough for the applications that need to use
it, as these applications typically involve some POST requests.

But we have been through this before, and I see no sense in repeating
my arguments for detectability by the origin server again.  I'm
willing to trade detectability for "must-revalidate".

>  It isn't the protocol's job to say when a
>client must make a request over the net -- in fact, it cannot do so.

Agreed.

>The only thing the protocol can do is allow both sides to state their
>desires and require that a warning be displayed if the result contradicts
>those desires.

Warning mechanisms which have a good chance of working are only things
I want.

[...]
>In practice, it will work just fine -- paranoia about the border cases
>(where the user always wins because they are the ones making the request)
>is just wasting time.

Commercial sites have all reason to be paranoid about border cases.
Ask Shel Kaphan.

>  If it doesn't work, then those pages will be
>marked as no-cache and the whole issue is moot. 

Huh?  So you think that caches willing to ignore max-age=0 and
must-revalidate will not be willing to ignore no-cache?  I don't think
so.

And anyway, if all stateful services have to use no-cache to guarantee
that users of PDAs won't shoot themselves in the foot, we have lost,
because this means that we have not improved on the current
cache-unfriendliness required if a stateful service wants to be
reliable.

[...]
>Adding another cache-control header is another waste of time -- it will
>be ignored for the same reason that max-age=0 was ignored.  

If we give must-revalidate stronger warning requirements if ignored
than we give to max-age=0, then must-revalidate would be a valuable
addition to the protocol.  Especially if the must-revalidate warning
is so loud that advertising sites will not be tempted to use
must-revalidate in order to get higher hitcounts, because the
associated loud warnings would keep away the public.

If we do not add must-revalidate, then clients will not be able to
tell legitimate revalidation requests by stateful services apart from
illegitimate ones by anti-social advertising sites.  If we only have
max-age=0, there is a real danger that such advertising sites will
cause proxy cache operators to ignore all max-age=0 directives, and
that such advertising sites will cause user agent authors to provide
options for switching off the warning about staleness.  The result
would be that a few anti-social sites will cause the
forms+CGI+cookies+revalidation interface to become completely unusable
as a base for providing reliable stateful services on the Web.

Now, some people think the forms+CGI+cookies+revalidation interface
does not deserve help anyway now that we have Java.  Other people will
see no reason to make the forms+CGI+cookies+revalidation interface
work, because their forms+CGI+session-id-in-the-url+cache-busting
interface works now, even though it is cache unfriendly.  I hold
neither of these views.

[...]
>So, what I have already said many times already is that the protocol
>should be defined according to how it will be used.

No objection from me here.

>  In this case, we
>need a warning message that must be displayed if the user is viewing
>a stale document (for whatever reason) in spite of the server's
>requirements for freshness.

I agree to a warning, *but this has to be done right*.  I want warning
mechanisms which have a good chance of working.

There is a real risk that frivolous use of max-age=0 will lead to
configurable options in user agents to switch off the staleness
warnings.  Must-revalidate with my proposed text provides a way around
this risk.

> ...Roy T. Fielding

Koen.

Received on Tuesday, 9 April 1996 22:00:23 UTC