@reporter: A workaround may be to serve your redirect no-store as well.

Interaction of redirect and LOAD_SKIP_CACHE_VALIDATION, I think.


t=27789 [st=  2]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=27789 [st=  2]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                        --> GET /Misc/chromeredirect/a.html HTTP/1.1
                            Host: www.hempel.cx
                            Connection: keep-alive
                            User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36
                            Upgrade-Insecure-Requests: 1
                            Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                            Accept-Encoding: gzip, deflate
                            Accept-Language: en-US,en;q=0.9
                            Cookie: [7 bytes were stripped]
t=27789 [st=  2]     -HTTP_TRANSACTION_SEND_REQUEST
t=27789 [st=  2]     +HTTP_TRANSACTION_READ_HEADERS  [dt=84]
t=27789 [st=  2]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=84]
t=27873 [st= 86]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 302 Found
                            Server: nginx/1.12.2
                            Date: Tue, 07 Nov 2017 14:12:49 GMT
                            Content-Type: text/html; charset=iso-8859-1
                            Content-Length: 294
                            Connection: keep-alive
                            Set-Cookie: [82 bytes were stripped]
                            Location: http://www.hempel.cx/Misc/chromeredirect/a.html
t=27873 [st= 86]     -HTTP_TRANSACTION_READ_HEADERS
t=27873 [st= 86]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=27873 [st= 86]      HTTP_CACHE_WRITE_DATA  [dt=0]
t=27873 [st= 86]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=27873 [st= 86]      URL_REQUEST_DELEGATE  [dt=0]
t=27873 [st= 86]      URL_REQUEST_DELEGATE  [dt=1]
t=27874 [st= 87]      URL_REQUEST_REDIRECTED
                      --> location = "http://www.hempel.cx/Misc/chromeredirect/a.html"
t=27874 [st= 87]   -URL_REQUEST_START_JOB
t=27874 [st= 87]    URL_REQUEST_DELEGATE  [dt=0]
t=27874 [st= 87]   +URL_REQUEST_START_JOB  [dt=1]
                    --> load_flags = 37124 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | SKIP_CACHE_VALIDATION | VERIFY_EV_CERT)
                    --> method = "GET"
                    --> url = "http://www.hempel.cx/Misc/chromeredirect/a.html"
t=27874 [st= 87]      URL_REQUEST_DELEGATE  [dt=0]
t=27874 [st= 87]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=27874 [st= 87]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
t=27874 [st= 87]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=27874 [st= 87]      HTTP_CACHE_READ_INFO  [dt=0]
t=27874 [st= 87]      URL_REQUEST_DELEGATE  [dt=0]
t=27874 [st= 87]      URL_REQUEST_DELEGATE  [dt=1]
t=27875 [st= 88]      URL_REQUEST_REDIRECTED
                      --> location = "http://www.hempel.cx/Misc/chromeredirect/a.html"
t=27875 [st= 88]   -URL_REQUEST_START_JOB
t=27875 [st= 88]    URL_REQUEST_DELEGATE  [dt=0]
(... snip a lot of attempts ..)
t=27896 [st=109] -REQUEST_ALIVE
                  --> net_error = -310 (ERR_TOO_MANY_REDIRECTS)


... And then something higher level retries.

Edit: Vary: Cookie on the redirect would also probably also work, and is arguably cleaner semantically...

Excellent work, and thank you for the workaround. I tested setting both Cache-Control and Vary: Cookie with my repro site and both resolve the issue.

Yeah, Vary: Cookie is the right way to do this. If your resource depends on some header value, you want to list the headers in the Vary header so that caches know not when cache entries are and aren't applicable.

It looks like we used to implicitly Vary: Cookie on redirects and this was removed in https://codereview.chromium.org/1965833002.

Playing around with Firefox, they do not implicitly add a Vary: Cookie, but they do randomly special-case cached self-redirects. I attached a quick test server. If I load /self_redirect in Firefox, it appears to fetch things three times:

  /self_redirect with no cookie => 302 Found self-redirect
  /self_redirect, load from cache => 302 Found self-redirect
  /self_redirect bypassing the cache? => 200 OK

So that means it's not working around the lack of Vary and actually detecting the behavior later and retrying.

Looks like it's this logic here:
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#5639

If they find a cached self-redirect, then they drop the cache entry before continuing. This won't work for cached redirect loops or anything though. Just the special-case of self-redirect.

Since this is ultimately a bug with the site, the workaround is kind of a hack, and the test page has since been fixed, I think we should close this WontFix on our end. Random special-cases like this are bad for the web platform and we seem to have managed without that workaround for 18 months now. +annevankesteren for Firefox.

Deleted: vary_cookie.go 1.1 KB

vary_cookie.go 1.1 KB View Download

(I don't believe the back button dance is needed to repro this when the resource has explicit Cache-Control headers.)

Thanks, filed https://bugzilla.mozilla.org/show_bug.cgi?id=1419348.