This was tested on a completely new profile.
I have also been experiencing this for months. Using Ubuntu 14.04 and Firefox 38
I can reproduce this using the steps from comment 0 with the doubleclick tracking pixel on Stack overflow. Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Confirmed on Windows nightly as well.
OS: Linux → All
Hardware: x86_64 → All
I can confirm this is happening on any js / css / image request on stackoverflow. If you edit and resend the original page request itself it seems to work. I'm not seeing it on localhost or bugzilla.mozilla.org. I wonder if this has to do with CDN hosted resources.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 982603
I don't think this should be marked as a duplicate. It's not clear to me that it's the same issue.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Bumped into this while doing some XHR snooping, makes the feature very broken. As in, not sure it should be whiteboarded with polish-backlog.
This has been happening to me and has been fairly frustrating so I did a little digging tonight. All requests going to the same domain (including sub-domain) and protocol as the page itself will work fine, all other requests will get set to OPTIONS (not just from GET but from POST and PUT and I assume all the others as well) For my testing I opened a random page (this page will work for the domain part but if you change from https to http the network panel seems to run into a different bug) went to the network panel did edit and resend with made up urls to see what Firefox would set as the method. It doesn't matter if the resource exists as we only care about the request not the response.
This is not the bug you are looking for.</jediMindTrick> This is how CORS works in browsers. Since your request is crossing the origin boundary, and it's non-simple, the browser automatically issues a preflight request with the OPTIONS action. If it passes, you should see the original request be resent. That's as it should be. HOWEVER, there is a bug. The browser looks at your original request and generates a special preflight header called Access-Control-Request-Headers that lists all the non-simple headers you will be sending. But when you do a resend, the browser sees your original headers AND the ones it automatically adds to the request, such as "User-Agent" and "Cache-Control". If the server is not specifically authorizing those headers, the preflight request will fail. There is a bug, but not the one you think.
You need to log in before you can comment on or make changes to this bug.