"Edit and Resend" changes request method from GET to OPTIONS

NEW
Unassigned

Status

defect
4 years ago
8 months ago

People

(Reporter: victor.engmark, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
Dependency tree / graph

Firefox Tracking Flags

(firefox38 affected, firefox38.0.5 affected, firefox39 affected, firefox40 affected, firefox41 affected, firefox42 affected)

Details

(Whiteboard: [polish-backlog])

Reporter

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150113033800

Steps to reproduce:

1. Go to https://stackoverflow.com
2. Open the Firefox Developer Tools
3. Go to the "Network" tab
4. Do a full reload (Ctrl-Shift-r)

At this point, I get the error message "Stack Overflow requires external JavaScript from another domain, which is blocked or failed to load." This turned out to be jquery.min.js from ajax.googleapis.com, so I tried debugging:

5. Right-click the failed GET request for jquery.min.js and select "Edit and Resend"
(6. Verify that the request method field says "GET")
7. Click "Send"
8. Click on the new request line at the bottom of the "Network" tab


Actual results:

The new request says that the request method was "OPTIONS".


Expected results:

The request method should be the same as the original request; "GET", not "OPTIONS".

This also works for other files on the same page, such as ados.js from engine.adzerk.net, but *not* for all URLs. For example, using "Edit and Resend" on "/" produces another GET request.

This is not a display issue; I've confirmed using Wireshark and the filter 'http.request.method == "OPTIONS"'.
Reporter

Updated

4 years ago
Component: Untriaged → Developer Tools: Netmonitor
Reporter

Comment 1

4 years ago
This was tested on a completely new profile.

Comment 2

4 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: firefox-backlog?
Version: 35 Branch → Trunk
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.
Whiteboard: [polish-backlog]

Updated

4 years ago
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 → ---
Status: REOPENED → NEW
Bumped into this while doing some XHR snooping, makes the feature very broken. As in, not sure it should be whiteboarded with polish-backlog.

Comment 9

3 years ago
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.
Flags: firefox-backlog?
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.

Updated

a year ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.