Re: Caching authentication state [giving too much control to clients?]

OK, thanks. It sounds like if I want credential caching, it does need  
to be defined by an extension. My use case is for gateways (reverse  
proxies/surrogates/etc.), but I could see inside-the-firewall cases  
where the origin server would also want to allow proxies to do it  
(explicitly).

As an aside, the text as specified seems to allow a message like this:

GET /foo HTTP/1.1
Host: www.example.com
Cache-Control: no-cache
Authentication Basic base64(what:ever)

to force an intermediary to revalidate a representation upon each  
request, until the representation actually changes.

This is because the requirement effectively gives control of the  
representation's cacheability to the client, *beyond* the scope of  
the interaction it is part of. When the cache goes to validate future  
requests, the origin server will happily respond with 304 Not  
Modified, and any freshness information it includes will be ignored.  
Only when the origin server replaces the cached representation (e.g.,  
with a 200 OK) will the state about authentication be removed, thus  
allowing it to avoid refresh.

Do others see this vulnerability?

In any case, I don't see it as a huge problem*; I guess theoretically  
it could be used to craft an attack that reduces cache efficiency --  
if implementations conform to this requirement. I just think it's odd  
to give this kind of control to the client.

Cheers,

* Though I am tempted to go out and put CC: public on pages where I  
really care about cacheability!


On 2006/03/11, at 11:28 AM, Roy T. Fielding wrote:

> On Mar 10, 2006, at 3:08 PM, Mark Nottingham wrote:
>> a) Is the intent of the first SHOULD to allow credential caching  
>> (e.g., similar to [1]) in intermediaries?
>
> No, the intent is to allow credential caching in user agents (the only
> creatures to whom Authorization applies).
>
> The rest of the section you quoted is irrelevant overspecification of
> the simple fact that responses to a request containing Authorization
> are not shared-cacheable unless explicitly made so by the origin  
> server
> header fields (that are more than adequately defined elsewhere, making
> those additions here confusing).
>
> ....Roy

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Monday, 13 March 2006 18:32:53 UTC