Re: Questions (errata?) about caching authenticated responses [#174]

Well, most of the proposal is defining what 'explicitly given otherwise' means (and noting the consequences)...

Which is more clear?

> Shared caches MUST NOT use a cached response to a request with an Authorization [ref] header to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.

or 

"""
Requests with Authoration [ref] headers MUST have the same effect as Cache-Control: private [ref] on the response.
"""


On 08/06/2010, at 12:40 PM, Roy T. Fielding wrote:

> Wouldn't it be easier to just say Authorization implies
> "Cache-control: private" unless explicitly given otherwise?
> 
> ....Roy
> 
> 
> On Jun 7, 2010, at 6:33 PM, Mark Nottingham wrote:
> 
>> I haven't heard any comment on this proposal. I *think* it accurately reflects what's in 2616, and AFAICT from the history, what's in 2616 was intentional. 
>> 
>> Thoughts?
>> 
>> 
>> On 02/06/2010, at 2:54 PM, Mark Nottingham wrote:
>> 
>>> 
>>> Counter-proposal:
>>> 
>>> Add a new section to p6:
>>> 
>>> ---8<---
>>> Shared Caching of Authenticated Responses
>>> 
>>> Shared caches MUST NOT use a cached response to a request with an Authorization [ref] header to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
>>> 
>>> In this specification, the following Cache-Control response directives [ref] have such an effect: must-revalidate, public, s-maxage.
>>> 
>>> Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be served stale [ref] by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy a subsequent request without revalidating it on the origin server. 
>>> --->8---
>>> 
>>> ... with appropriate changes to p6 2.1, 2.2, as well as the definitions of the Auth header and appropriate CC directives.
>> 
>> 
>> --
>> Mark Nottingham     http://www.mnot.net/
>> 
>> 
> 


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 8 June 2010 05:03:34 UTC