RE: Caching authentication state

Mark,

See inline. This is my interpretation of the text and answer to your
questions.

- Joris

>-----Original Message-----
>From: ietf-http-wg-request@w3.org 
>[mailto:ietf-http-wg-request@w3.org] On Behalf Of Mark Nottingham
>Sent: zaterdag, 11 maart 2006 0:09
>To: ietf-http-wg@w3.org
>Subject: 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?

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.

[snip]
>
>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).
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.
Therefore I believe the desired behaviour should be that, if s-maxage is
added to a request, an intermediate is always allowed to cache the
response for anyone. Otherwise there should not be a marking that a
shared cache may cache it.
You MUST NOT return the cached information when it is expired. However,
it seems to be perfectly acceptable to try to revalidate if the content
did change (e.g. if-modified-since).

Also, the sentence before the numbered list gives an indication that we
are talking about NOT returning it to any request, UNLESS.

>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.

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

Probably, your last 'statement' already gives the answers to the other
questions, implicitly.
Clients send their authentication prematurely (to prevent likely
additionals round trips) and therefore caching directives from the
server override the (weak) indication of the client that the content
probably requires authentication.

>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.

My EUR .02,

- Joris

Received on Saturday, 11 March 2006 17:27:57 UTC