If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

tabzilla.js: 200 instead of 304

VERIFIED FIXED

Status

Websites
Tabzilla
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: julienw, Unassigned)

Tracking

Details

(Whiteboard: [kb=1082536] )

(Reporter)

Description

4 years ago
STR:
* go to https://www.mozilla.org/en-US/privacy/policies/firefox-os/
* open the "network" panel in either Dev Tools or Firebug
* press F5

Expected:
* a request is sent for tabzilla.js with the saved ETag, and the 304 response is received

Actual:
* a request is sent for tabzilla.js with the saved ETag, and a 200 response is received with the file content and the very same ETag

The full URL for this file is https://mozorg.cdn.mozilla.net/en-US/tabzilla/tabzilla.js?build=6279ac9

It's also very easy to reproduce with curl :

  curl -I -H 'ETag: "262ccf01c615952458a258a2b7c8b896"' https://mozorg.cdn.mozilla.net/en-US/tabzilla/tabzilla.js?build=6279ac9

Note that it works as expected for the other .js files (maybe because they end with -min.js ?)
Adding Jake Maul as this seems like it may be a CDN issue.
Flags: needinfo?(nmaul)
(Reporter)

Comment 2

4 years ago
I think it is not related to CDN, the same happens on allizom, see:

curl -I -H 'ETag: "dcd44c306a52efc01006f0220c313297"' https://www.allizom.org/en-US/tabzilla/tabzilla.js?build=80b5249

Pascal Chevrel told me this file is regenerated on the server (like once every few hours) in contrary to other files, so it might be the reason.
(In reply to Julien Wajsberg [:julienw] from comment #2)
> I think it is not related to CDN, the same happens on allizom, see:
> 
> curl -I -H 'ETag: "dcd44c306a52efc01006f0220c313297"'
> https://www.allizom.org/en-US/tabzilla/tabzilla.js?build=80b5249
> 
> Pascal Chevrel told me this file is regenerated on the server (like once
> every few hours) in contrary to other files, so it might be the reason.

You should use 'If-None-Match: "dcd44c306a52efc01006f0220c313297"'

With this, dev(www-dev.allizom) and stage(www.allizom) always give me 200, but prod(www.mozilla) sometimes gives me 304 ... hmmm
(In reply to Hector Zhao [:hectorz] from comment #3)
> 
> With this, dev(www-dev.allizom) and stage(www.allizom) always give me 200,
> but prod(www.mozilla) sometimes gives me 304 ... hmmm

stage also give me 304 now
(Reporter)

Comment 5

4 years ago
(In reply to Hector Zhao [:hectorz] from comment #3)
> (In reply to Julien Wajsberg [:julienw] from comment #2)
> > I think it is not related to CDN, the same happens on allizom, see:
> > 
> > curl -I -H 'ETag: "dcd44c306a52efc01006f0220c313297"'
> > https://www.allizom.org/en-US/tabzilla/tabzilla.js?build=80b5249
> > 
> > Pascal Chevrel told me this file is regenerated on the server (like once
> > every few hours) in contrary to other files, so it might be the reason.
> 
> You should use 'If-None-Match: "dcd44c306a52efc01006f0220c313297"'
> 

ooops right

on www.allizom, and www.mozilla, I get 200 at the first get, and 304 then.
on dev, it's always 200 like you found.

However, if I do the reload STR on https://www.mozilla.org/en-US/privacy/policies/firefox-os/, I always get a fresh copy of that file (according to the dev tools).
(In reply to Julien Wajsberg [:julienw] from comment #5)
> (In reply to Hector Zhao [:hectorz] from comment #3)
> > (In reply to Julien Wajsberg [:julienw] from comment #2)
> > > I think it is not related to CDN, the same happens on allizom, see:
> > > 
> > > curl -I -H 'ETag: "dcd44c306a52efc01006f0220c313297"'
> > > https://www.allizom.org/en-US/tabzilla/tabzilla.js?build=80b5249
> > > 
> > > Pascal Chevrel told me this file is regenerated on the server (like once
> > > every few hours) in contrary to other files, so it might be the reason.
> > 
> > You should use 'If-None-Match: "dcd44c306a52efc01006f0220c313297"'
> > 
> 
> ooops right
> 
> on www.allizom, and www.mozilla, I get 200 at the first get, and 304 then.
> on dev, it's always 200 like you found.
> 
> However, if I do the reload STR on
> https://www.mozilla.org/en-US/privacy/policies/firefox-os/, I always get a
> fresh copy of that file (according to the dev tools).

My guess: django will only set/check ETag/If-None-Match header with settings.USE_ETAGS = True, but bedrock set ETag header on tabzilla js even if settings.USE_ETAGS is False, causes browser to send If-None-Match header. But the backend used by CDN doesn't check it and only return 200.

PR 1133 makes sure bedrock only set ETag header when settings.USE_ETAGS is True
(Reporter)

Comment 7

4 years ago
How do you explain that it works for the other js files (site-min.js, common-resp-min.js, privacy-firefoxos-min.js then?
(In reply to Hector Zhao [:hectorz] from comment #6)
> PR 1133 makes sure bedrock only set ETag header when settings.USE_ETAGS is
> True
Just realize setting USE_ETAGS to True will cause django to compute ETag for every page. I updated the PR to make it possible to return 304 in bedrock.tabzilla.views.tabzilla_js even if USE_ETAGS is False

(In reply to Julien Wajsberg [:julienw] from comment #7)
> How do you explain that it works for the other js files (site-min.js,
> common-resp-min.js, privacy-firefoxos-min.js then?
As you mentioned in comment 2, other files are just static files, they are not served by bedrock the django app.
In my testing with curl it does seem to be behaving correctly from www.mozilla.org, but not from mozorg.cdn.mozilla.net. So I still think this is a CDN issue in that it doesn't seem to be respecting the If-None-Match header. I don't think :hectorz's PR is necessary since zeus (our caching proxy/load-balancer) seems to be handling the caching on our end correctly. Hopefully :jakem will get back to us soon.
(In reply to Paul McLanahan [:pmac] from comment #9)
> In my testing with curl it does seem to be behaving correctly from
> www.mozilla.org, but not from mozorg.cdn.mozilla.net. So I still think this
> is a CDN issue in that it doesn't seem to be respecting the If-None-Match
> header. I don't think :hectorz's PR is necessary since zeus (our caching
> proxy/load-balancer) seems to be handling the caching on our end correctly.
> Hopefully :jakem will get back to us soon.

Just realize if my guess is correct, tabzilla js at www.mozilla.org will not return any 304 ... sorry for the additional confusion

Updated

4 years ago
Whiteboard: [kb=1082536]

Comment 11

4 years ago
Sorry for the delay. This is an interesting one!

A few things to cover here....

The .js files that work seem to be mostly (entirely?) the static kind. The primary difference is that they have a "Last-Modified" header attached to the outgoing response, and an incoming "If-Modified-Since" header on the requests. I believe this is why they get 304'd... not the ETag.

If you query Zeus with an "If-None-Match", it seems to return a 304 *only if* the file is already in Zeus's cache. If it's not, it appears to return a 200. This makes things somewhat unpredictable.

I suspect that Akamai (the CDN powering mozorg.cdn.mozilla.net) probably does not handle If-None-Match... or perhaps it's just forwarding from Zeus, and the aforementioned quirk there is causing most responses to be 200's instead of 304's.


My recommendation here would be to try to get Django to send a Last-Modified header with these requests. That seems to work more reliably than ETags.
Flags: needinfo?(nmaul)
I'm sure we can make that happen. Thanks :jakem!

Updated

4 years ago
Component: Pages & Content → Tabzilla
Product: www.mozilla.org → Websites
Target Milestone: --- → 1.5
Sorry for the bugspam -- the Target Milestore was set unexpectedly.
Target Milestone: 1.5 → ---

Comment 14

4 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/0cbe9c764ecc09e8de74bbedf723f6f3ec953906
Bug 900426 - tabzilla.js: 200 instead of 304

https://github.com/mozilla/bedrock/commit/75187635781b9d46d1950905484496c0db606fa5
Bug 900426: Add tests for new decorator.

https://github.com/mozilla/bedrock/commit/c3ff2231c0a3953ca035ee78c35cda81af95389e
Merge pull request #1591 from pmclanahan/l-hedgehog-bug-900426-lastmodified-tabzilla-js

Bug 900426 - tabzilla.js: 200 instead of 304
fixed on stage https://www.allizom.org/en-US/privacy/policies/firefox-os/
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
verified fixed

https://www.mozilla.org/en-US/privacy/policies/firefox-os/
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.