W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Cache behavior for authenticated contents

From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Sat, 27 Feb 2010 03:52:45 +0900
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <87sk8n96de.fsf@bluewind.rcis.aist.go.jp>

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

# We found it during implementing our protocol proposal,
# but this is independent from the proposal.

We've built a small interactive demonstration at
<http://t01.rcis.jp/moz-auth-cache-bug/>.  The behavior on recent
Mozilla browsers is as follows:

  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.

     # In this demo, a "401 page" is not older than "200 pages".

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

Up to our trials, the behavior 1 was observed only on Mozilla, but
the behavior 2 was also observed on several other browsers (e.g. IE and Safari).

# The interactive demonstration above will give an instruction for
# Mozilla (because it is used for bug reporting), but you can try it
# on another browser with some efforts.

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

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)
does not expect that an authenticated user turns back to
unauthenticated user, which was not possible in early browsers.

How do you feel about these behaviors of current browsers?
How do you think about adding an explicit clause something like
"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?

# FYI, the related bug ID for mozilla is #533412.

# It may be related to the httpbis WG issue #174, and I agree with the
# assumption in clause 4 there (authenticated responses should be
# able to be cached).

Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]
Received on Friday, 26 February 2010 18:53:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT