- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 1 Jan 1997 21:45:40 +0100 (MET)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: abaird@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul:
>
>As you point out, this language in 14.8:
>
> 1. If the response includes the "proxy-revalidate" Cache-Control
> directive, the cache MAY use that response in replying to a
> subsequent request, but a proxy cache MUST first revalidate it with
> the origin server, using the request-headers from the new request
> to allow the origin server to authenticate the new request.
>
>either contradicts or modifies this language in 14.9.4:
>
> When the must-revalidate directive is present in a response
> received by a cache, that cache MUST NOT use the entry after it
> becomes stale to respond to a subsequent request without first
> revalidating it with the origin server. [...] The proxy-revalidate
> directive has the same meaning as the must- revalidate directive,
> except that it does not apply to non-shared user agent caches.
>
>I think we've agreed that this is a bug in the specification. That
^^^^^^^^^^^^
>is, we did not intend that the meaning of this cache-control directive
>should change when another response header is present.
For the record, if you are using the word `bug' not just to mean `we
intended it differently', but also to mean `this is a fatal problem
that must be fixed', I do _not_ agree that this is a bug in the
specification. In my reading, 14.8 does *not* modify or contradict
14.9.4.
14.9.4 talks about restrictions implied by proxy-revalidate.
14.8 talks about restrictions implied by the Authorization header
which happen to be _lifted_ when proxy-revalidate is present.
Koen.
Received on Wednesday, 1 January 1997 12:52:47 UTC