1958245 - Firefox not caching 303 redirects

Status: RESOLVED FIXED

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

Comment 4

[Andrew Creskey [:acreskey]]

Attachment: Bug 1958245 - Firefox not caching 303 redirects r=#necko-reviewers

Per updated RFCs, we will cache resources from 303 redirects for performance reasons.

Comment 5

[Andrew Creskey [:acreskey]]

Thanks Oskar.
It appears that the change to nsHttpResponseHead::MustValidate() to make this redirect status cacheable does fix the issue for me. But I've put the WIP patch up for early thoughts.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/273a954c9a4a
https://hg.mozilla.org/integration/autoland/rev/65c52287c66f
Firefox not caching 303 redirects r=necko-reviewers,valentin

Comment 7

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/65c52287c66f

Comment 8

[Andrew Creskey [:acreskey]]

Thank you for reporting this and providing the details and analysis, Leon.
We've fixed this in Firefox 147, updating our caching logic to match the latest RFC.

Comment 9

[Andrew Creskey [:acreskey]]

Attachment: 303_before_after_compare.mp4

On your site the performance and overall experience improvement is quite noticeable.

On the left we see a refresh with the previous Firefox behaviour: not caching the 303 redirects
On the right we see a refresh with the new Firefox behaviour, caching the 303 redirects. Almost instantaneous.

Comment 10

[Leon Stringer]

That's a great improvement. Thanks everyone who worked on this. Looking forward to Fedora giving me the update.