Re: Cache behavior for authenticated contents

lör 2010-02-27 klockan 03:52 +0900 skrev Yutaka OIWA:

> We found some behaviors on several web browsers on caching
> authenticated contents which we think these are unexpected.

Why unecpected?


>   1) A 401 response is cached if a Last-Modified header is there, and
>      "If-unmodified-since" is sent to the server for authenticated request.
>      Thus, the authenticated response will be 304 status and an
>      "Authentication Required" page will be shown instead.

Congratulations, server just shoot itself in the foot by saying things
about the 401 response which isn't really relevant to the 401 response.

But yes, any cache caching such responses can be argued being broken as
there is no explicit expiry time set, or other explicit indications that
the response may be cached. But one MAY read the specification as if
cache validators (Last-Modified, ETag) also implies tat the response is
cachable.


>   2) If an authenticated response is cached, it is reused from cache
>      even when a user has been logged off or logged in again for another user.
>      (many recent browsers have some way to log off without clearing the
>       memory cache).

HTTP specs do not limit the browser private cache to login sessions. The
browser cache is assumed to be personal to the end user.

But the protocol do have provisions for saying that some responses
should not be stored as they are to sensitive even for storing in a
private cache (no-store directive).

> In my opinion, the behavior 1 is clearly a bug (non-conformity to
> RFC 2616), because a 401 response is forbidden to be cached unless there
> is either a Cache-control: or a Expires: header.

or "another header(s) that explicitly allow it." which unfortunately
isn't defined clearly.

The first paragraph here talks about cache validators, and is why those
may be thought of as beloning to that "another header(s)" set.

>  I also think behavior
> 2 is very annoying, and conflicts with a concept of "authentication".
> However, I could not find an explicit clause for prevent the 2nd behavior.
> Note that "Cache-control: private" may not work, because browser
> caches are considered as "Non-shared caches".

"Cache-Control: private" should not make any difference. Iẗ́'s the
default state on any authenticated content.

> I think, at least naively, that a cached contents for user A should
> not be used for user B nor for an unauthenticated user, unless there
> is a "Cache-control: public" (or a similar) header.  I guess that the
> current model of a "non-shared cache" in RFC (and current draft, too)

Correct. The RFC assumes that the browser cache is non-shared, unique to
a single user.

> How do you feel about these behaviors of current browsers?

No opinion.

> "An authenticated response MUST NOT be reused unless the a request is
> authenticated with a same realm and a user name", will it be a change
> incompatible with current HTTP spec?

I do not think we can make that a MUST, as it's a new requirement and
would render major existing implementations noncompliant. May be
possible to add it as a SHOULD level requirement.

Regards
Henrik

Received on Friday, 14 May 2010 10:09:18 UTC