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

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Florian.P.Nierhaus]

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

Comment 1

[Florian.P.Nierhaus]

Firefox 45.0a2 (2016-01-25) works correct.

Comment 2

[Florian.P.Nierhaus]

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.

Comment 3

[Patrick McManus [:mcmanus]]

you mention 44 and 42 as a range. 43 involved moving where the preflight was done.. bug 1199049..

Comment 4

[Florian.P.Nierhaus]

So firefox 43 works

Comment 5

[(no longer active)]

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.

Comment 6

[(no longer active)]

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!

Comment 7

[Florian.P.Nierhaus]

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.

Comment 8

[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

Comment 9

[(no longer active)]

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!

Comment 10

[Florian.P.Nierhaus]

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.

Comment 11

[Florian.P.Nierhaus]

Also it works when the browser is in incognito mode...

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

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?

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Actually, before dup'ing... How is this CORS request being made?  Is it through fetch() in the main window?

Comment 14

[(no longer active)]

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.

Comment 15

[Florian.P.Nierhaus]

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

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

Do you have a bug open for your websocket issue?  We should investigate that.

Comment 17

[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

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 19

[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.

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

Ok, thanks.  Reproduced locally on an updated beta.  Very weird.

Let me take a look.

Comment 21

[(no longer active)]

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.)

Comment 22

[Anne (: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.

Comment 23

[(no longer active)]

Thanks, I'll fix that part in bug 1243453.

Comment 24

[Patrick McManus [:mcmanus]]

(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?

Comment 25

[Ben Kelly [:bkelly, not reviewing]]

This is unrelated to bug 1237455.  The site is using xhr instead of fetch.  Still investigating whats going on.

Comment 26

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 27

[(no longer active)]

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.  :(

Comment 28

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 29

[(no longer active)]

(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.  :-)

Comment 30

[Ben Kelly [:bkelly, not reviewing]]

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 31

[Ben Kelly [:bkelly, not reviewing]]

Attachment: P1 nsCORSListenerProxy should copy headers on internal redirects. r=ehsan

Comment 32

[Ben Kelly [:bkelly, not reviewing]]

Attachment: P2 Test XHR with a non-intercepting service worker. r=ehsan

Comment 33

[Ben Kelly [:bkelly, not reviewing]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c098034d0a3

Comment 34

[(no longer active)]

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.

Comment 35

[(no longer active)]

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?

Comment 36

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 37

[Ben Kelly [:bkelly, not reviewing]]

Attachment: P2 Test XHR with a non-intercepting service worker. r=ehsan

Comment 38

[Michal Novotny [:michal]]

Attachment: WS patch

(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?

Comment 39

[Patrick McManus [:mcmanus]]

Comment on attachment 8714543 [details] [diff] [review]
WS patch

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

yep

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 41

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 42

[Ben Kelly [:bkelly, not reviewing]]

(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.

Comment 43

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(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?

Comment 44

[Ben Kelly [:bkelly, not reviewing]]

(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?

Comment 45

[Ben Kelly [:bkelly, not reviewing]]

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!

Comment 46

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 48

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 49

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 50

[Ben Kelly [:bkelly, not reviewing]]

Attachment: P1 Make nsCORSListenerProxy call UpdateChannel() for internal redirects. r=sicking

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!

Comment 51

[Ben Kelly [:bkelly, not reviewing]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=36cb3326356e

Comment 52

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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`?

Comment 53

[Ben Kelly [:bkelly, not reviewing]]

Attachment: P1 Make nsCORSListenerProxy call UpdateChannel() for internal redirects. r=sicking

Comment 54

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/642aa364f5ae
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c8c41a4678e

Comment 55

[Michal Novotny [:michal]]

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

Comment 56

[Ben Kelly [:bkelly, not reviewing]]

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!

Comment 57

[Michal Novotny [:michal]]

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.

Comment 58

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 59

[Sylvestre Ledru [:Sylvestre]]

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 60

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8714497 [details] [diff] [review]
P2 Test XHR with a non-intercepting service worker. r=ehsan

See comment 58.

Comment 61

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/642aa364f5ae
https://hg.mozilla.org/mozilla-central/rev/9c8c41a4678e

Comment 62

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 63

[Kohei Yoshino [:kohei]]

Posted the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/cross-site-xmlhttprequest-is-blocked-due-to-missing-origin-header/

Comment 64

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a34fa9f8840a
https://hg.mozilla.org/releases/mozilla-aurora/rev/f6c1f509a1b2

Comment 65

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ce0284c11a0a
https://hg.mozilla.org/releases/mozilla-beta/rev/727076193304

Comment 66

[Adrian Holovaty]

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.

Comment 67

[Kohei Yoshino [:kohei]]

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.

Comment 68

[Ben Kelly [:bkelly, not reviewing]]

(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.

Comment 69

[Kohei Yoshino [:kohei]]

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.

Comment 70

[Ben Kelly [:bkelly, not reviewing]]

(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 71

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 72

[Kohei Yoshino [:kohei]]

Updated the site compat doc based on Ben's comments: https://www.fxsitecompat.com/en-CA/docs/2016/cross-site-xmlhttprequest-is-blocked-if-service-worker-is-used-without-fetch-event-handler/

Comment 73

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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!

Comment 75

[lasersox]

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?