Closed
Bug 900426
Opened 11 years ago
Closed 10 years ago
tabzilla.js: 200 instead of 304
Categories
(Websites :: Tabzilla, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: julienw, Unassigned)
Details
(Whiteboard: [kb=1082536] )
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 ?)
Comment 1•11 years ago
|
||
Adding Jake Maul as this seems like it may be a CDN issue.
Flags: needinfo?(nmaul)
Reporter | ||
Comment 2•11 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.
Comment 3•11 years ago
|
||
(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
Comment 4•11 years ago
|
||
(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•11 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).
Comment 6•11 years ago
|
||
(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•11 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?
Comment 8•11 years ago
|
||
(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.
Comment 9•11 years ago
|
||
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.
Comment 10•11 years ago
|
||
(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•11 years ago
|
Whiteboard: [kb=1082536]
Comment 11•11 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)
Comment 12•11 years ago
|
||
I'm sure we can make that happen. Thanks :jakem!
Updated•11 years ago
|
Component: Pages & Content → Tabzilla
Product: www.mozilla.org → Websites
Target Milestone: --- → 1.5
Comment 13•11 years ago
|
||
Sorry for the bugspam -- the Target Milestore was set unexpectedly.
Target Milestone: 1.5 → ---
Comment 14•10 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
Comment 15•10 years ago
|
||
fixed on stage https://www.allizom.org/en-US/privacy/policies/firefox-os/
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 16•10 years ago
|
||
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.
Description
•