Missing Origin header in Cross Origin Request resulting in Cross-Origin Request Blocked

RESOLVED FIXED in Firefox 45

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: Florian.P.Nierhaus, Assigned: bkelly)

Tracking

({dev-doc-complete, regression, site-compat})

44 Branch
mozilla47
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 wontfix, firefox45 fixed, firefox46 fixed, firefox47 fixed)

Details

()

Attachments

(2 attachments, 4 obsolete attachments)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36

Steps to reproduce:

Site https://blab.im

Our site makes requests to https://api.blab.im with custom headers resulting in CORS requests. This works fine in Firefox 42.

In Firefox 44 we now see an OPTIONS preflight request with Origin header and then a GET w/o Origin header and then firefox indicating

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.blab.im/user/feed?count=50. (Reason: CORS header 'Access-Control-Allow-Origin' missing).



Actual results:

Here are there the firefox 44 request & response headers, note that there i no Origin header in the GET request.

OPTIONS https://api.blab.im/user/feed?count=50

Host: api.blab.im
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-riano-user-agent
Origin: https://blab.im
Connection: keep-alive

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-Riano-User-Agent,Content-Type,Authorization,X-Requested-With,Content-Length,Accept,Origin,X-Api-Key,X-Access-Token
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin: https://blab.im
Access-Control-Max-Age: 1800
Allow: HEAD,GET,OPTIONS
Connection: keep-alive
Content-Length: 0
Content-Type: text/html
Date: Wed, 27 Jan 2016 17:38:31 GMT
Server: nginx/1.7.10


GET https://api.blab.im/user/feed?count=50

Host: api.blab.im
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://blab.im/
X-Riano-User-Agent: riano_prod/0.4.146 (Web) riano_api/1
Connection: keep-alive


Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json
Date: Wed, 27 Jan 2016 17:38:31 GMT
Server: nginx/1.7.10
Transfer-Encoding: chunked
Vary: Accept-Encoding


Expected results:




In Firefox 42 there is no pre-flight OPTIONS check and the GET has the Origin Header and everything works.

GET https://api.blab.im/user/feed?count=50

Host: api.blab.im
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Access-Token: xxxxxxxxxxxxx
X-Riano-User-Agent: riano_prod/0.4.146 (Web) riano_api/1
Referer: https://blab.im/
Origin: https://blab.im
Connection: keep-alive
Cache-Control: max-age=0

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://blab.im
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json
Date: Wed, 27 Jan 2016 17:57:19 GMT
Server: nginx/1.7.10
Transfer-Encoding: chunked
Vary: Accept-Encoding
Firefox 45.0a2 (2016-01-25) works correct.
If you want to test you will have to do that somewhere else. We implemented a workaround for firefox 44 to send CORS headers independent of the presence of the Origin header.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
you mention 44 and 42 as a range. 43 involved moving where the preflight was done.. bug 1199049..
Flags: needinfo?(jduell.mcbugs)
Flags: needinfo?(ehsan)
So firefox 43 works
Hmm, we have made quite a few changes to our CORS code in this time frame.  Bug 1199049 may or may not be the cause.  We set the Origin header in nsCORSListenerProxy::UpdateChannel() and I can't really explain why we would lose that after a successful preflight.  :(

Florian, is it possible for you to give us access to some code which triggers the bug without going through the workaround that you mentioned, perhaps as a hidden test page on your site?  That would help us a lot to debug this.
Flags: needinfo?(ehsan) → needinfo?(Florian.P.Nierhaus)
Also, we have a tool called mozregression which downloads and runs Firefox builds to help you find a regression range.  If you can't share a public test case, it would be really nice if you can give it a shot and see if you can find the first Firefox build where we broke this.  The tool's home page is <http://mozilla.github.io/mozregression/>.

Thanks for your help on this so far!
Currently you can hit https://blab.im and see the problem in action.

Forcing the cors issues didn't get us all the way. We could make our api requests, but websocket didn't establish. "Firefox can't establish a connection to the server at wss://ws.blab.im/ws."

As an aside - with a hard reload the page works - if you just reload or go it doesn't.
Flags: needinfo?(Florian.P.Nierhaus)
I could not find a nightly build with the issue ;-)

firefox-44.0a1.en-US.linux-x86_64.tar.bz2
2015-10-28 00:09:09.039000, revision 39af5c53
does not have the issue.

44.0b1 has the issue
Thanks for the further investigation!  I wonder if the reason you didn't see the issue on Nightly was because of the dates you tried.  Note that the code that is included in a Nightly at a given date goes to beta several weeks later, and the time difference is not really even easy to estimate (since sometimes a critical fix is backported from Nightly to Beta after only a few days!)

How can I see the issue exactly?  I tried loading the main page and I see no OPTIONS request in the Network panel, nor any accesses to <https://api.blab.im/user/feed?count=50>.  I thought that maybe that only happens when I log in, so I logged in using Twitter, and I get stuck at <https://blab.im/welcome/step-2>.  I see the following in the console:

TypeError: t is not a function
 blab.f9bbee2b2168b2a2366d.js:26:14788

Thanks!
Thank you!

Not sure what is going on with the t is not a function.

You should be able to reproduce the CORS issue by just going to https://blab.im and then do a reload.

For some reason it works the first time and when we do a hard reload.
Also it works when the browser is in incognito mode...
This site has a service worker with only a push event handler.  I'm 99% sure this is a dupe of bug 1237455.  That bug is fixed in FF45.

The short term workaround is to add this to your service worker:

  addEventListener('fetch', function(evt) {
    evt.respondWith(fetch(evt.request));
  });

Does that help?
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1237455
Actually, before dup'ing... How is this CORS request being made?  Is it through fetch() in the main window?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(Florian.P.Nierhaus)
Resolution: DUPLICATE → ---
Hmm, I downloaded builds before and after bug 1237455 landed, and it does look like before that bug was fixed, there is an OPTIONS request in the network panel followed by a POST (to https://api.blab.im/events) which doesn't have an Origin header.  After that, I see no OPTIONS request (which is a bug in our devtools, bug 1214752) and a POST to the same URL which does have the Origin header.  Based on that, it looks like Ben is right!

If that bug is indeed the cause, the workaround in comment 12 should fix it for Firefox 44.
Thank you !!!!

The workaround fixed the CORS issues but we still were stuck because we couldn't open websockets.

So we disabled service workers for Firefox 44 and that seems to have fixed both.

Regarding the fetch() question - I don't think we do - we still use jQuery for those requests and I believe it doesn't use fetch yet - but not really sure.

We are using the service worker for notifications in chrome and plan to do the same in firefox (I guess 45).

Thanks again,
Florian
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(Florian.P.Nierhaus)
Resolution: --- → DUPLICATE
Duplicate of bug: 1237455
Do you have a bug open for your websocket issue?  We should investigate that.
Flags: needinfo?(jduell.mcbugs) → needinfo?(Florian.P.Nierhaus)
Hi Ben, I don't have a bug open for that. I felt that the websocket issue is related.

Also I don't know what version to actually test - somehow the nightly builds always work for me and the release builds don't.

See my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1237455#c65

Also just tested a nightly that I thought would not have a fix for 1237455 and it worked:
2016-01-19-00-40-10-mozilla-aurora/firefox-45.0a2.en-US.linux-x86_64
Flags: needinfo?(Florian.P.Nierhaus)
Can you describe what you are seeing with the websockets here then?  I'm not seeing it.  In theory websockets should completely bypass service workers.
Flags: needinfo?(Florian.P.Nierhaus)
"Firefox can't establish a connection to the server at wss://ws.blab.im/ws."

If you use 45.0b1 (where we still install a service worker) and go to https://blab.im you can see the issue.

Reload (to make sure you have the service worker installed) and you will see the CORS issues in the console.

As you won't get to the place where we open the websocket, in the console do:

var ws = new WebSocket("wss://ws.blab.im/ws", [])

And you get:

Firefox can't establish a connection to the server at wss://ws.blab.im/ws.

We don't even see packets coming from the browser.

For control you can open www.google.com, open the console and do the same and you won't see the error.
Flags: needinfo?(Florian.P.Nierhaus)
Ok, thanks.  Reproduced locally on an updated beta.  Very weird.

Let me take a look.
Assignee: nobody → bkelly
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I debugged the WebSocket failure issue.  We hit this code <https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannel.cpp#3022> (which seems a very strange way to check for HSTS redirects!  Why doesn't it just check for REDIRECT_STS_UPGRADE?)

But more importantly, WebSocket handshake channels should always bypass service workers, I think.  Anne, is that true?

(Adding nsIChannel::LOAD_BYPASS_SERVICE_WORKER to <https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/websocket/WebSocketChannel.cpp#2665> fixes the WebSocket part of this bug.)
Flags: needinfo?(mcmanus)
Flags: needinfo?(annevk)
Yeah, we have not figured out the exact intersection of WebSocket and Fetch so it remains a special case and should bypass service workers.
Flags: needinfo?(annevk)
Depends on: 1243942
Thanks, I'll fix that part in bug 1243453.
(In reply to :Ehsan Akhgari from comment #21)
> I debugged the WebSocket failure issue.  We hit this code
> <https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/websocket/
> WebSocketChannel.cpp#3022> (which seems a very strange way to check for HSTS
> redirects!  Why doesn't it just check for REDIRECT_STS_UPGRADE?)
>

I can't think of a good reason.. it should allow both INTERNAL and STS_UPGRADE.

michal maintains this code, so maybe he would be so kind as to write the patch?
Flags: needinfo?(mcmanus) → needinfo?(michal.novotny)
This is unrelated to bug 1237455.  The site is using xhr instead of fetch.  Still investigating whats going on.
The issue here is that nsCORSListenerProxy only calls its UpdateChannel() for non-internal redirects.  So it fails to set the origin header on the new channel.  We didn't catch this with the fetch tests because fetch sets its own origin header.
Ugh, is this the NS_IsInternalSameURIRedirect() call in https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#652 preventing the call to UpdateChannel()?  I think this is really bug 1240929.  :(
Depends on: 1240929
Yes, but I don't think we're going to fix bug 1240929 in time to fix this in beta.  I have a patch that just makes nsCORSListenerProxy always run UpdateChannel on successful redirect.
(In reply to Ben Kelly [:bkelly] from comment #28)
> Yes, but I don't think we're going to fix bug 1240929 in time to fix this in
> beta.  I have a patch that just makes nsCORSListenerProxy always run
> UpdateChannel on successful redirect.

Yeah agreed.  What we need to do here is to do some small local surgery to get this one instance fixed, and keep it backportable, but fix bug 1240929 properly on trunk in 47 to avoid finding and fixing more instances in other places that we haven't checked yet.  Please let me know if you're going to do the latter too.  :-)
I do not plan to do the refactor of all internal redirects, no.  I feel like I am already kind of buried in issues and that sounds like it could have a large number of problems to sort out.
Comment on attachment 8714443 [details] [diff] [review]
P1 nsCORSListenerProxy should copy headers on internal redirects. r=ehsan

Review of attachment 8714443 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good but I'd like sicking to also take a look.

One thing that made me hesitate here is that NS_IsHSTSUpgradeRedirect() and NS_IsInternalSameURIRedirect() also check the actual URLs of the old and new channel, not just checking the flag which is surprising to me.  That may or may not be important here.
Attachment #8714443 - Flags: review?(ehsan) → review?(jonas)
Comment on attachment 8714444 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

Review of attachment 8714444 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/workers/test/serviceworkers/fetch_event_worker.js
@@ +1,4 @@
>  var seenIndex = false;
>  
>  onfetch = function(ev) {
> +  if (ev.request.url.includes("skipme")) {

Nit: can you please call this "ignore" to match the web-platform-tests convention?
Attachment #8714444 - Flags: review?(ehsan) → review+
For this particular bug I don't need to copy the headers for HSTS.  Its unclear to me what should happen in the HSTS case.  Happy to make that case do nothing for now if we think its safer.

(In reply to :Ehsan Akhgari from comment #35)

> ::: dom/workers/test/serviceworkers/fetch_event_worker.js
> > +  if (ev.request.url.includes("skipme")) {
> Nit: can you please call this "ignore" to match the web-platform-tests
> convention?

I thought I could not because it already uses "ignored.txt" elsewhere, but it wants the same behavior.  So matching on ignore should work for both cases.
Posted patch WS patch (obsolete) — Splinter Review
(In reply to Patrick McManus [:mcmanus] from comment #24)
> I can't think of a good reason.. it should allow both INTERNAL and
> STS_UPGRADE.

Did you mean something like this?
Flags: needinfo?(michal.novotny)
Attachment #8714543 - Flags: feedback?(mcmanus)
Comment on attachment 8714543 [details] [diff] [review]
WS patch

Review of attachment 8714543 [details] [diff] [review]:
-----------------------------------------------------------------

yep
Attachment #8714543 - Flags: feedback?(mcmanus) → feedback+
Comment on attachment 8714443 [details] [diff] [review]
P1 nsCORSListenerProxy should copy headers on internal redirects. r=ehsan

Review of attachment 8714443 [details] [diff] [review]:
-----------------------------------------------------------------

Couldn't you simply call UpdateChannel and pass in the redirected channel?
I guess the other thing that I'm surprised about is that necko doesn't copy over *all* headers when an internal or HSTS redirect happens.

We have all sorts of code which creates channels and sets headers on it. Does every single such callsite need to handle this condition?
(In reply to Jonas Sicking (:sicking) from comment #40)
> Couldn't you simply call UpdateChannel and pass in the redirected channel?

No.  That causes things to fail when UpdateChannel() calls CheckPreflightNeeded():

https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#978

(In reply to Jonas Sicking (:sicking) from comment #41)
> I guess the other thing that I'm surprised about is that necko doesn't copy
> over *all* headers when an internal or HSTS redirect happens.
> 
> We have all sorts of code which creates channels and sets headers on it.
> Does every single such callsite need to handle this condition?

That is bug 1240929, but we need this to be upliftable to beta in order to fix this in 45.  I don't think we can uplift a necko-wide change to all internal redirects to beta.
(In reply to Ben Kelly [:bkelly] from comment #42)
> No.  That causes things to fail when UpdateChannel() calls
> CheckPreflightNeeded():

Give UpdateChannel and CheckPreflightNeeded a |bool aInternalRedirect| argument which skips that check?
(In reply to Jonas Sicking (:sicking) from comment #43)
> Give UpdateChannel and CheckPreflightNeeded a |bool aInternalRedirect|
> argument which skips that check?

I think that would work for internal same-url redirect, but it would probably flip mHasBeenCrossSite to true for HSTS redirects.  Is that desired?
I could also do the UpdateChannel with new flag for internal same-url redirect only, and then leave HSTS untouched as it is today.  Thoughts?  I have to log off now, but will make the changes tomorrow.

Thanks!
Flags: needinfo?(jonas)
I was thinking setting the argument to true for both HSTS and internal redirects. Which might mean that something other than "aInternal" would be better.

But yes, I think taking that approach would be better.
Flags: needinfo?(jonas)
Oh, i see about mHasBeenCrossSite.

Yes, I think that is desirable.

If the new URL is cross-origin, then mHasBeenCrossSite should be set to true.

If the new URL is not cross-origin, then mHasBeenCrossSite won't be set to true.

In the latter situation mHasBeenCrossSite might have already been set to true when UpdateChannel was called on the pre-hsts-redirect channel. But that seems like a separate bug if so (and we might actually have some code to handle that case).

Or am I missing something?
The new URL will always be cross origin in hsts upgrade case.  Seemed like we were trying to exempt the upgrade itself from cors checks.
I guess I will also need to figure out what to pass for the data uri param.  I think I can pass "allow" since any disallow checking would have failed for the original channel in the same-uri case.  And for hsts upgrade it should not be triggering for a data uri anyway.
Is this what you had in mind?  I'm still unsure about the HSTS case here.  I'm not even sure how to trigger it in a test.  Since I want to upload to beta, I would be happy to leave the HSTS case as doing nothing in this redirect callback handler.

Thoughts?

Thanks!
Attachment #8714443 - Attachment is obsolete: true
Attachment #8714443 - Flags: review?(jonas)
Attachment #8715494 - Flags: review?(jonas)
Comment on attachment 8715494 [details] [diff] [review]
P1 Make nsCORSListenerProxy call UpdateChannel() for internal redirects. r=sicking

Review of attachment 8715494 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with that

::: netwerk/protocol/http/nsCORSListenerProxy.h
@@ +39,5 @@
>  
> +enum class UpdateType
> +{
> +  Default,
> +  InternalRedirect

Can we call this `InternalOrHSTSRedirect`?
Attachment #8715494 - Flags: review?(jonas) → review+
Comment on attachment 8714543 [details] [diff] [review]
WS patch

If I haven't overlooked anything all the intermittent failures are already known.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=79e8ceb06e17&selectedJob=16302639
Attachment #8714543 - Flags: review?(mcmanus)
Michal, can we move this to a separate bug?  I just landed the CORS header stuff in this one and it might get confusing with multiple fixes going on.  Sorry for the inconvenience!
Flags: needinfo?(michal.novotny)
Comment on attachment 8714543 [details] [diff] [review]
WS patch

(In reply to Ben Kelly [:bkelly] from comment #56)
> Michal, can we move this to a separate bug?  I just landed the CORS header
> stuff in this one and it might get confusing with multiple fixes going on. 
> Sorry for the inconvenience!

Sure.
Attachment #8714543 - Flags: review?(mcmanus)
Attachment #8714543 - Attachment is obsolete: true
Flags: needinfo?(michal.novotny)
Comment on attachment 8715827 [details] [diff] [review]
P1 Make nsCORSListenerProxy call UpdateChannel() for internal redirects. r=sicking

Approval Request Comment
[Feature/regressing bug #]: Service workers.
[User impact if declined]: Sites are seeing cross-origin requests failing due to missing CORS headers when service workers are registered.  This is for sites not intercepting network requests.  This is a bad regression and needs to be fixed ASAP.
[Describe test coverage new/current, TreeHerder]: Tests included.
[Risks and why]: Moderate risk given we are touching the CORS code.
[String/UUID change made/needed]: None.
Attachment #8715827 - Flags: approval-mozilla-beta?
Attachment #8715827 - Flags: approval-mozilla-aurora?
It will probably missed 45 beta 3: I cannot take this patch right now as it didn't land in m-c.

Hopefully, this will land in beta 4.
Comment on attachment 8714497 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

See comment 58.
Attachment #8714497 - Flags: approval-mozilla-beta?
Attachment #8714497 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/642aa364f5ae
https://hg.mozilla.org/mozilla-central/rev/9c8c41a4678e
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Comment on attachment 8714497 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

Fix a bad regression, taking it.
Should be in 45 beta 4.
Attachment #8714497 - Flags: approval-mozilla-beta?
Attachment #8714497 - Flags: approval-mozilla-beta+
Attachment #8714497 - Flags: approval-mozilla-aurora?
Attachment #8714497 - Flags: approval-mozilla-aurora+
Attachment #8715827 - Flags: approval-mozilla-beta?
Attachment #8715827 - Flags: approval-mozilla-beta+
Attachment #8715827 - Flags: approval-mozilla-aurora?
Attachment #8715827 - Flags: approval-mozilla-aurora+
Hi there -- my site soundslice.com is getting bitten by this (it makes a cross-domain Ajax query, which is now failing in Firefox 44). Is there a workaround? I've read through the thread here but haven't seen an obvious workaround.
I have experienced a similar issue before (Bug 687758) and at that time, I made a simple server-side proxy script that read resources from an external site, so that I could avoid cross-origin XHRs.
(In reply to Adrian Holovaty from comment #66)
> Hi there -- my site soundslice.com is getting bitten by this (it makes a
> cross-domain Ajax query, which is now failing in Firefox 44). Is there a
> workaround? I've read through the thread here but haven't seen an obvious
> workaround.

The issue occurs when the service worker does not handle the fetch event.  So you can work around the problem by doing this:

  addEventListener('fetch', function(evt) {
    evt.respondWith(fetch(evt.request));
  });

The real fix will be in FF45.
Actually these bug comments are pretty confusing. A part of this has been moved to Bug 1243942, and the original report is not about service workers, right? It would be great if someone could summarize the situation well.
(In reply to Kohei Yoshino [:kohei] from comment #69)
> Actually these bug comments are pretty confusing. A part of this has been
> moved to Bug 1243942, and the original report is not about service workers,
> right? It would be great if someone could summarize the situation well.

The issue is with how parts of gecko handle internal redirects (redirects that do not change the URL of the resource).  Service workers use internal redirects when a request is not intercepted to reset the channel.  It turns out many things, like cors, drop headers on internal redirects.

The web socket thing is a different issue, which is why it was moved to a different bug.  Service workers should not intercept the web socket negotiation channel at all.
Comment on attachment 8714497 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

Would like to include all patches here as a ride-along if we do another point release.
Attachment #8714497 - Flags: approval-mozilla-release?
Comment on attachment 8714497 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

I don't see a strong reason for this to be uplifted to a dot release. I would prefer to let this ride the beta45 -> release45 train. Thanks!
Attachment #8714497 - Flags: approval-mozilla-release? → approval-mozilla-release-
Duplicate of this bug: 1248463
I am seeing this issue on firefox 52.0.2

You can see it yourself here: lasersox.net.

Using firefox, clicking "submit" you'll get a 500 response. If you check headers, you will Firefox does not include an origin.

I am not using service workers (though I am using jquery.post).

Is it a regression or a new bug?
You need to log in before you can comment on or make changes to this bug.