415086 - Redirect responses are not cached although cacheable

Status: RESOLVED INCOMPLETE

(Core :: Networking: Cache, defect)

Description

[Carsten Leue]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SU 3.011; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; MAXTHON 2.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

I have a scenario where

(1) a GET request to URL1 returns a 301 response code and a location header that points to URL2 (+ cache headers)
(2) a GET request to URL2 returns a 200 response code and some content (+ cache headers)

The response to (1) looks like this:

HTTP/1.1 301 Moved Permanently
Location: <URL2>
Expires: Tue, 29 Jan 2008 13:45:15 GMT
Date: Mon, 28 Jan 2008 13:45:15 GMT
Cache-Control: private, max-age=86400
Content-Language: de-DE
Transfer-Encoding: chunked
Server: WebSphere Application Server/6.1

0

The result I'd like to see is that both the response to (1) and to (2) get cached, i.e. the browser remembers that (1) will redirect to (2) and the retrieves (2) from the cache, too.
The result I'm actually seeing is that (1) is not cached, i.e. always results in a browser roundtrip, whereas (2) is cached (FireFox 2.0.0.11)

RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2) specifies: "This response is cacheable unless indicated otherwise. "

So the redirect response should be cached.

Reproducible: Always

Steps to Reproduce:
1. write a website that redirects from URL1 to URL2 and marks the redirect response as cacheable
2. start a HTTP tunnel to monitor the outgoing requests
3. access URL1, FF should redirect to URL2 and display the result. The HTTP tunnel should show two outgoing requests
4. access URL1 again, FF should redirect but the tunnel should not show any outgoing request
Actual Results:  
In step 4 FF shows an outgoing request to URL1 and only fetches the response to URL2 from the browser cache

Expected Results:  
In step 4 there should be no outgoing request, both responses from accessing URL1 and URL2 should come from the browser cache

Comment 1

[Carsten Leue]

Google Chrome now supports caching of redirect responses. I think that this is a significant performance improvement and that Firefox should also consider fixing this bug.

Comment 2

[Eric Lawrence]

I had a look at this in Firefox 3.6, and it appears that 301, 302, and 307 responses will all cache if a Caching header is returned that allows it. 303 responses are (correctly, per RFC2616) forbidden to cache regardless of header.

The remaining bug here is that Firefox requires a 301 to have a header that allows caching to cache the redirect; the RFC suggests that no such directive should be required.

Meddler (www.fiddler2.com/meddler/) test case attached.

Comment 3

[Eric Lawrence]

Attachment: Meddler test script for testing browser redirect caching behavior

Comment 4

[Eric Lawrence]

Attachment: Updated version of MeddlerScript with no query string for 301 case.

Use http://www.fiddler2.com/meddler/ to view. Open //127.0.0.1:8088 in your browser and watch network traffic

Comment 5

[Eric Lawrence]

The problem demonstrated in the attached case is actually that Firefox will not cache a 301 *if* that 301 doesn't have a Cache-permitting header AND the URL that requested the 301 contains a ? (query string delimiter). 

That was likely deliberate due to the RFC2616 clause about response cacheability when the request contains a querystring (since excised from the updated spec by the HTTPBIS working group).

So, overall, this bug appears to be bogus except in one very very specific case (e.g. Request with query string, response is 301 without header indicating that it may be cached).

Comment 6

[Eric Lawrence]

I've done more comprehensive testing here, and the first thing I found likely explains what the original reporter hit.

• Firefox 4.0Beta will bypass a cached redirect if there are ANY cookies in the request headers. This greatly limits the value of redirection caching in Firefox. This was likely done to try to avoid redirect loops.
• Firefox 4.0Beta will illegally cache a HTTP/302 redirect with no Cache-Control or Expires header if a Last-Modified header is present.
• Firefox 4.0Beta will not cache a 303 redirect even if headers are present that allow it (E.g. Cache-Control: private or Cache-Control: max-age=1200). 
• Firefox 4.0Beta will not cache a 301 redirect whose request contained a querystring unless there are explicit caching headers; this is a result of them attempting to respect an obscure clause in RFC2616 which suggests that responses with query string shouldn't be cacheable without such headers. This clause is being removed by the HTTPBIS working group.
• Firefox 4.0Beta doesn't cache 302, 303, 307 redirects with Cache-Control: private unless a Last-Modified header is present (enabling calculation of heuristic lifetime).

(Uploading new test script)

Comment 7

[Eric Lawrence]

Attachment: Newest Meddler test case probing all aspects of redirect caching

Comment 8

[Tim (fmdeveloper)]

Kicking this to the component that I think may be correct (based on searching for similar bugs related to caching/headers)...

Eric -> How do you run/interpret the results from Meddler? I downloaded it and installed. Then I ran the script and it ran in IE in a loop loading images. I didn't see any visible results aside from the counter at the top of the page? Do I need to be watching the results in Fiddler or something?

Would love to get this checked on Firefox 5 and the latest nightlies.

Comment 9

[Eric Lawrence]

@Tim: You can watch the network requests in a network monitoring tool, or you can use the LOG tab in Meddler (look at the bottom) to see the requests that were sent to the network. From that, you can tell which requests were sent to the server vs. which were served from the cache.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Could someone retest this on trunk, please?  In particular, item 1 from comment 6 has been fixed since that comment was made...

Carsten, I would especially appreciate you either pointing to a testcase or doing an HTTP log per https://developer.mozilla.org/en/HTTP_Logging in a trunk build; without that it's really hard to say what you're seeing.

Comment 11

[Patrick McManus [:mcmanus]]

presuming wfm