1635532 - Cache-Control: immutable does not always work

Status: RESOLVED INVALID

(Core :: Networking: Cache, defect)

Description

[Eric Lawrence (@ericlaw)]

Attachment: ImmutableIsNot.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 Edg/81.0.416.68

Steps to reproduce:

1. Visit https://bayden.com/test/cache/refresh.aspx
2. OBSERVE: All subdownloads are green, indicating that they were fetched anew and caching/validation headers were NOT sent on the request.
3. Hit REFRESH in the browser UI
4. OBSERVE: Some resources turn PURPLE, indicating that a conditional validation request to the server was sent. This is EXPECTED for resources without |immutable|.
5. Hit REFRESH a few more times (e.g. seven).

{
"application": {
"name": "Firefox",
"osVersion": "Windows_NT 10.0",
"version": "78.0a1",
"buildID": "20200505094621",
"distributionID": "",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0",
"safeMode": false,
"updateChannel": "nightly",
"supportURL": "https://support.mozilla.org/1/firefox/78.0a1/WINNT/en-US/",
"numTotalWindows": 1,
"numRemoteWindows": 1,
"launcherProcessState": 0,
"remoteAutoStart": true,
"autoStartStatus": 1,
"policiesStatus": 0,
"keyLocationServiceGoogleFound": true,
"keySafebrowsingGoogleFound": true,
"keyMozillaFound": true
},

Actual results:

6. OBSERVE: Some of the resources served with the IMMUTABLE cache-controlling directive are refetched, with a |Cache-Control: max-age=0| request header and no |If-None-Match| request header that would allow revalidation.

Expected results:

EXPECT: Cached-resources with Cache-Control immutable should never be re-fetched, unless the user clears their cache or hits CTRL+Refresh.

https://bugzilla.mozilla.org/show_bug.cgi?id=1267474

Comment 1

[Eric Lawrence (@ericlaw)]

Attachment: about:cache details of a CSS file unexpectedly refetched despite immutable directive

Comment 2

[Kershaw Chang [:kershaw]]

Michal, could you take a look?
Thanks.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

I wonder if this is RCWN related, with the network winning? Or maybe the server is just recording the network request even though the cache won?

Comment 4

[Eric Lawrence (@ericlaw)]

I'm not completely sure what RCWN is?

"Or maybe the server is just recording the network request even though the cache won?"

The red response being used in the page after reload was served by the server in response to the unexpected revalidation request.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

(In reply to Eric Lawrence (@ericlaw) from comment #4)

I'm not completely sure what RCWN is?

RCWN is Race Cache With Network. When we detect the cache file access is slow, we sometimes send the network request too, and use whichever response comes back first.

"Or maybe the server is just recording the network request even though the cache won?"

The red response being used in the page after reload was served by the server in response to the unexpected revalidation request.

Thanks!

Comment 6

[Eric Lawrence (@ericlaw)]

Ah, "Race Cache With Network"?

This repro on a Samsung 970 Pro SSD, so I'd expect the cache to be very very fast (and further assuming that we're not using the memory cache for whatever reason).

In some refreshes with the DevTools open, I do see "(raced)" after some of the resource requests, but I haven't yet managed to reproduce the problem (that is to say, see the server-regenerated resource in page) with the devtools open.

Comment 7

[Michal Novotny [:michal]]

(In reply to Eric Lawrence (@ericlaw) from comment #0)

EXPECT: Cached-resources with Cache-Control immutable should never be re-fetched, unless the user clears their cache or hits CTRL+Refresh.

I'm not sure I understand the problem. Do you see a conditional request for immutable resource? Immutable resources do not have to be re-validated with the server. But it's perfectly OK to re-fetch them if we decide to not use the entry for whatever reason.

Comment 8

[Eric Lawrence (@ericlaw)]

@Valentin: Fascinating! I think your psychic debugging is correct.

In my testing, disabling |network.http.rcwn.enabled| makes the repro go away (immutable resources always reused from cache).

Setting |min_wait_before_racing_ms| to |5| also makes the repro go away.

@Michal: The "problem" is that |immutable| is used for two reasons: 1) to reduce load on servers, and 2) to improve performance on clients. Usually, |immutable| provides both. RCWN provides the fascinating outcome that achieves #2 without #1.

Comment 9

[Michal Novotny [:michal]]

Closing as invalid because we don't send conditional requests for immutable resources that are not stale.

Comment 10

[Eric Lawrence (@ericlaw)]

To confirm the intent of the resolution, you're saying that it's BYDESIGN that

"Firefox sometimes sends unconditional requests for immutable resources (that are not stale)."

Comment 11

[Michal Novotny [:michal]]

(In reply to Eric Lawrence (@ericlaw) from comment #10)

To confirm the intent of the resolution, you're saying that it's BYDESIGN that

"Firefox sometimes sends unconditional requests for immutable resources (that are not stale)."

Right. In general, we prefer loading the page quickly over saving the bandwidth. This is not true e.g. when mobile data is used etc.