Re: Caching authentication state

On 2006/03/11, at 9:27 AM, Joris Dobbelsteen wrote:
>>
>> a) Is the intent of the first SHOULD to allow credential
>> caching (e.g., similar to [1]) in intermediaries?
>
> No, I do not believe it should be done. I believe an immedediary  
> should
> never touch authentication (only detect its presence for caching
> reasons).
>
> This restriction looks for the 'server-side' only. IF  
> authentication for
> the same realm is requested, this means the same authentication
> authority is used. This unless the authentication method decides
> otherwise.
> No behaviour for the client or intermediate seems to be required.

Well, it's ambiguous. You can read that it's only server-side, but  
that's not explicit.

>> 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?
>
> The intermediate simply CANNOT verify the authentication[2]. It
> therefore seems completely unlogic to expect an immediate to do so in
> any way. It cannot even check if the digest credentials match those of
> the previous request (provided e.g. the nonce).

The text above alludes to the fact that some auth schemes have this  
limitation, but not all do (e.g., Basic, or a token-based scheme,  
should such a thing ever appear).

> It is also impossible to determinate if a connection is from a single
> user, not using IP address (another intermediate), not using the same
> connection (another intermediate), not even using proxy credentials.

Not sure how this is relevant.

>> 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.
>
> Indeed, therefore, if a response contains s-maxage or public, it most
> likely doesn't need authentication anyways. Therefore, if you see
> explicit indications that it is publicly cacheable, it will probably
> have a good reason.
> The client can also use the cache-control in the response, which is
> probably much more effective anyways.

This requires servers to send cache-control on all content that might  
be authenticated, or clients to divine when to send c-c request  
headers. Considering how little deployment both see, it's not a very  
practical approach.

>> 1. http://www.mnot.net/drafts/draft-nottingham-http-auth-cache-00.txt
> 2. I cannot determinate if immediates acting on behalf of a origin
> server (reverse proxy) are not considered in the RFC. Therefore I  
> asume
> they are not.

Sure they are;

> gateway
> A server which acts as an intermediary for some other server.  
> Unlike a proxy, a gateway receives requests as if it were the  
> origin server for the requested resource; the requesting client may  
> not be aware that it is communicating with a gateway.

Cheers,

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

Received on Saturday, 11 March 2006 18:13:42 UTC