Closed Bug 533412 Opened 15 years ago Closed 8 years ago

Cache look-up should consider authenticated user names

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: y.oiwa, Unassigned)

References

()

Details

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.
That's a situation where the "Cache-Control: private" header should have been used ...
(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).
Blocks: 532127
Status: UNCONFIRMED → NEW
Ever confirmed: true
this is what vary is for
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.