The default bug view has changed. See this FAQ.

Cache look-up should consider authenticated user names

RESOLVED INVALID

Status

()

Core
Networking: HTTP
RESOLVED INVALID
7 years ago
a year ago

People

(Reporter: Yutaka OIWA, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5

Mozilla do not distinguish pages with same URL but authenticated by different credentials.  If the user visits the same page twice with different credentials, the cached page for the first user will be served for the second user.
The URL demonstrates the behavior.
To fix this, the cache should consider the user-names of the authentications as one of keys for cache look-up (as if it were specified in a header referenced by a Vary: header.)

The HTTP/1.1 spec (RFC 2616) only considers the situation where every authentication session is valid while the browser is not terminated.
This is no more true with the current Firefox implementation.
The current implementation of the browser is
something between the "public" and "private" caches defined in RFC 2616.

This bug covers previously submitted bug 374599 (in Fx 2.0), which was not severe in the previous situation (because there was no situations for TWO usernames in the same browser session).

Reproducible: Always

Steps to Reproduce:
Visit the pages shown in the URL field.
The pages returns "Last-modified:" headers for both 401 and 200 pages.
Actual Results:  
Cached unauthenticated pages will be shown for authenticated users, and cached pages for the user A will be shown for user B.

Expected Results:  
Cache entries should not be used when the usernames in the new request differ from that of a cached requests.

Confirmed on both Mozilla Firefox 3.5.5 and 3.0.15.

Comment 1

7 years ago
That's a situation where the "Cache-Control: private" header should have been used ...
(Reporter)

Comment 2

7 years ago
(In reply to comment #1)
> That's a situation where the "Cache-Control: private" header should have been
> used ...

No, 
this demo only returns a "Last-modified:" header and no Cache-Control, and
RFC 2616 says that shared caches (for which "Cache-Control: private" applies,
Sec. 14.9.1) should not cache responses to any requests which have "Authorization:" header (Sec. 14.8), unless it is explicitly
allowed by "Cache-control: public" and "Cache-control: s-maxage=...".

RFC also says that 401 responses should not be cached unless it has an explicit cache controlling header (Sec. 13.4).
(Reporter)

Updated

7 years ago
Blocks: 532127

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
this is what vary is for
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.