1958245 - Firefox not caching 303 redirects

Status: NEW

(Core :: Networking, defect, P2)

Description

[Leon Stringer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

I work with a web platform where images can be optionally served from cloud storage, S3 in our case. This redirects image requests to a URL containing a dynamic signature which changes per request. This means that every load of the image is redirected to a new URL so the image has to be fetched again. However, Chrome (tested v134.0.6998.35) caches the redirect so that the image URL is the same and thus subsequent loads of the image are fetched from the cache. Obviously this makes page loads faster on Chrome, much faster on image-heavy pages, for example, 6 seconds on Chrome versus 1+ minutes on Firefox when the cache is populated.

One can see this on our site's homepage, https://moodle.ucl.ac.uk. Using Chrome redirects to images are cached on first load so for subsequent loads both redirects and images are loaded from the cache thus subsequent page loads are faster. With Firefox the redirects are not cached, for every load of the page the images must be fetched again from the web again making each page load as slow as the first.

I'm reporting this as a defect based on Chrome's behaviour, but that may be an incorrect assumption/comparison – apologies if so.

(I first posted this in the support forum and was advised to create a new issue on Bugzilla).

For example, to load an image, the browser might do:

-> GET https://www.example.com/file.php/image01.jpg
<- HTTP/2 303 See Other
expires: Thu, 03 Apr 2025 11:23:44 GMT
cache-control: public, max-age=14400
location: https://[site].amazonaws.com/...filename%3D%22image01.jpg%22&X-Amz-Signature=...123

and the browser follows the redirect to get the image:

-> GET https://[site].amazonaws.com/...filename%3D%22image01.jpg%22&X-Amz-Signature=...123
<- 200 OK

I then reload the page...

Actual results:

...when I reload the page the signature is now different:

-> GET https://www.example.com/file.php/image01.jpg
<- HTTP/2 303 See Other
expires: Thu, 03 Apr 2025 11:24:03 GMT
cache-control: public, max-age=14400
location: https://[site].amazonaws.com/...filename%3D%22image01.jpg%22&X-Amz-Signature=...abc

and the URL to the image is fetched with a GET.

Expected results:

In Chrome if I reload the page there's the same following of the redirect when the page is first loaded, but when the page is refreshed the redirect has been cached:

-> GET https://www.example.com/file.php/image01.jpg
<- HTTP/2 303 See Other (from disk cache)
location: https://[site].amazonaws.com/...filename%3D%22image01.jpg%22&X-Amz-Signature=...123

Since the redirect is now to the same URL the image is fetched from the browser cache.

The "(from disk cache)" is shown in the developer tools.

Comment 1

[Kershaw Chang [:kershaw]]

Accord to the rfc 2616:

   The 303 response MUST NOT be cached, but the response to the second
   (redirected) request might be cacheable.

However, in the recent rfc, it doesn't mention this.
It seems Firefox should work like other browsers.

Comment 2

[Masatoshi Kimura [:emk]]

The new RFC explicitly says that any response with a final status code can be cached if the response has explicit freshness information.

Since 303 is a final status code and the response has freshness information (expires and max-age), Chrome complies with the latest RFC.
RFC 9111 has more detailed conditions.

Comment 3

[Oskar Mansfeld]

I had very briefly started looking at this last week but am now unassigning again to prioritize other work. Just quickly sharing what I found.

It's definitely still reproducible and even just visually very obvious if you compare to chrome how fast pictures on https://moodle.ucl.ac.uk/ reload.

I found some code in nsHttpChannel e.g. here that seems to mess with redirects, but I don't know if that's the right path. Removing that (or other checks on WillRedirect()) didn't change anything.