Caching authentication state

RFC 2616 section 14.8 says:

>       If a request is
>       authenticated and a realm specified, the same credentials SHOULD
>       be valid for all other requests within this realm (assuming that
>       the authentication scheme itself does not require otherwise,  
> such
>       as credentials that vary according to a challenge value or using
>       synchronized clocks).
>       When a shared cache (see section 13.7) receives a request
>       containing an Authorization field, it MUST NOT return the
>       corresponding response as a reply to any other request,  
> unless one
>       of the following specific exceptions holds:
>       1. If the response includes the "s-maxage" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But (if the specified maximum age has
>          passed) 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. (This  
> is the
>          defined behavior for s-maxage.) If the response includes "s-
>          maxage=0", the proxy MUST always revalidate it before re- 
> using
>          it.
>       2. If the response includes the "must-revalidate" cache-control
>          directive, the cache MAY use that response in replying to a
>          subsequent request. But if the response is stale, all caches
>          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.
>       3. If the response includes the "public" cache-control  
> directive,
>          it MAY be returned in reply to any subsequent request.

This section is confusing, so a few questions;

a) Is the intent of the first SHOULD to allow credential caching  
(e.g., similar to [1]) in intermediaries?

If so, it's pretty well hidden; so much so that I wrote a duplicative  
I-D after the fact ;)  This is a useful feature that AFAIK is not  
implemented by anyone; however, it has implications for  
authentication realms (i.e., they must be homogenous) that people may  
not realise.

b) Are the requirements regarding s-maxage predicated on the  
credentials being seen before? Or, does s-maxage allow subsequent  
requests to be served without credentials at all, or different  
credentials?

c) Specifying this behaviour ("When a shared cache...") in terms of  
requests containing an Authorization field effectively allows the  
client to control the cacheability of the response. However, clients  
often send the Authentication header pre-emptively to resources that  
don't need it, which may lead to sites being unnecessarily less  
cacheable.

I haven't looked at the core caching stuff in a while; am I missing  
something here?


1. http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt


Thanks,

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Friday, 10 March 2006 23:09:52 UTC