Re: Transparency vs. Performance: survey of opinion

Roy T. Fielding:
>Koen writes:
>> Two new cache-control request directives, "may-cache" and "min-age"
>> that indicate possible weakening of any "no-cache" and "max-age"
>> restrictions, would work for me.  ...
>I think that the proposed "max-stale" directive does indicate what
>Koen would like the client to indicate.

I just read the "stale-max" description in
draft-mogul-http-caching-00, and it indeed seems to indicate what I
want. "stale-max" would work like my "min-age".

>  "may-cache" would therefore
>be redundant.

I used "may-cache" to indicate that the client may disregard a
"no-cache" directive (since "no-cache" imposes stronger caching
restrictions than "max-age=0").  "may-cache" is not really needed to
solve the cookie reliability problem, so in that sense it is
redundant.  I added it for symmetry, and also because someone once
said that servers which send secure documents with no-cache will want
to know about it if the client will ignore this directive.


>In other words, I think we reached an acceptable compromise before
>this thread started.

I want a requirement that it not mentioned in draft-mogul:

  if the user loosens caching restrictions of the browser cache, the
  user agent _must_ send a stale-max directive in every request.

Without this _must_, a server which uses cookies cannot reliably send
warning messages in pages if the user has set the browser to "never

In another message, you write:
>Max-stale is better than a Cache-Warning on a request because the former
>provides a useful service for the browser, and thus the browser will be
>more likely to send it.

That is true. 

But could someone ever want to loosen caching restrictions of the
browser cache without loosening restrictions on proxy caches?  In that
case, there would be an incentive _not_ to send stale-max.

Maybe modem users will want a browser setting in which the browser
cache is set to "never check", without a "max-stale" being sent in
requests for pages not in the browser cache.  The rationale would be
"If I do have to wait for receipt of data over the phone line, I'd
rather have fresh data".

So here is what I propose:

Add two new cache-control request directives:

    "max-stale"       "=" stale-time 
    "local-max-stale" "=" stale-time


    stale-time = ( delta-seconds | "inf" )

  If the client is configured to pass on (after the user clicks a
  link, or, if the client is a proxy, after a request is received from
  a downstream client) responses from its local cache memory or from
  upstream servers which are stale-time seconds or less past their
  expiration time, then one of these directives _must_ be present in
  the request.  This is to give origin servers the chance to put
  warning messages in the response entities if the correct working of
  the service is not possible under such client configurations.

  If the client is willing to pass on stale responses from its own
  cache memory, but not willing to receive stale responses from
  upstream servers, it can use the "local-max-stale" directive.
  [Note: What is the semantics of a max-stale in a conditional GET
  request?  I don't believe this has been discussed yet.]
Are we converging?



Received on Friday, 1 March 1996 06:56:54 UTC