1206924 - FF dev tools wont add Access-Control-Request-Method in 'edit and resend'

Status: NEW

(DevTools :: Netmonitor, defect)

Description

[djFD]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150826185918

Steps to reproduce:

Similar to Bug 1107529, but a different header (Access-Control-Request-Method)
- Open developer tools
- Click Network tab
- Select the main HTML request; hit Edit Resend
- Add new header `Access-Control-Request-Method: POST'
- Set method to OPTIONS
- Click "Send"


Actual results:

request is being sent without this new header


Expected results:

expected to have it, ofc

Comment 1

[djFD]

just noticed the same situation with `Origin' header. Cannot add it too

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I don't think this should be marked as a duplicate.  It's not clear to me that it's the same issue.

Comment 4

[Naruki Bigglesworth]

We aren't supposed to send OPTIONS requests, the browser does that automatically when it sees you are making a CORS request.

It also scans your intended request for non-simple headers and puts them in the "Access-Control-Request-Headers" header.

Even if you just want to pretend to be the browser, it is going to scan your faux OPTIONS call and ... Who knows? It's not supposed to be used for this sort of thing.

You should be resending actual requests and let the browser handle preflights if needed.

---

And I don't think you're doing this, but just in case keep in mind that "Access-Control-Request-Method" cannot be OPTIONS, since that header is asking the server if you can use that method.

In other words, you can't send an OPTIONS call to tell the server you're requesting permission to send an OPTIONS call.

Comment 5

[djFD]

well, browser also can send, say, POST request on its own. And we still have an ability to edit any associated headers of such requests for a debugging.

Do you think OPTIONS requests do not need any debugging at all?

Comment 6

[Naruki Bigglesworth]

The point is that OPTIONS is only ever sent by browsers. The web dev has no control over that.

The purpose of the OPTIONS call is to let the cross-origin server know you are about to make a possibly dangerous call and what kind of properties your call will have. That's why the OPTIONS call does not include your actual headers or data body. It just describes what they will be.

If you make the same call from CURL or from a RESTClient, you won't see the OPTIONS call.

Making the call manually is an undefined behavior, and is not something you want to do inside the browser. If you _do_ want to test it manually, you need to use CURL or something else, AND be very sure you understand the headers you need to send, and what to expect back.

Comment 7

[djFD]

@Naruki Bigglesworth, yes I know what is intention of OPTIONS request when doing CORS requests. I faced the issue debugging very complicated a case of improperly working web server software, it is why. It is not a synthetic request, sometimes we need to do a things like that.

And honestly I cannot see any difference between adding any arbitrary header to POST request and adding the same to OPTIONS request.

Comment 8

[Naruki Bigglesworth]

Then you probably don't understand the CORS process fully.

IMO, that's normal since reading the spec or one of the many "how to" articles out there, I just can't find answers because they don't think of my questions.

You don't put arbitrary headers on the OPTIONS request. Period. Even if you do it from CURL.

There are a specific set of headers that should go on there, and they have restrictions on what values you can give them. Just as the server has a specific set of headers it can return.

And like I said, if you really need to issue your own OPTIONS request (such as when testing your server), then you should NOT do it from a browser. The browser parses your request and makes its own OPTIONS from that. If you are adding certain headers that should be okay, Firefox especially will screw up the OPTIONS request.

Do those tests from CURL or a RESTClient if you want better control. But you'll need to read a lot to make sure you are doing things exactly right.

Comment 9

[djFD]

(In reply to Naruki Bigglesworth from comment #8)
> Then you probably don't understand the CORS process fully.
> 
> IMO, that's normal since reading the spec or one of the many "how to"
> articles out there, I just can't find answers because they don't think of my
> questions.

may be this is sufficient? https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

> You don't put arbitrary headers on the OPTIONS request. Period. Even if you
> do it from CURL.
> 

again, Access-Control-Request-Method is not an arbitrary header, it is exactly as per spec

> There are a specific set of headers that should go on there, and they have
> restrictions on what values you can give them. Just as the server has a
> specific set of headers it can return.
> 
> And like I said, if you really need to issue your own OPTIONS request (such
> as when testing your server), then you should NOT do it from a browser. The
> browser parses your request and makes its own OPTIONS from that. If you are
> adding certain headers that should be okay, Firefox especially will screw up
> the OPTIONS request.

Well, continuing your thoughts, I have not use firefox for a debugging purposes, curl/wget is ok.
okay, going even further need I to switch to chromimum at all? why you decide what tools need I use? All fields/headers are perfectly as per spec, so why need I use any extra tools

> Do those tests from CURL or a RESTClient if you want better control. But
> you'll need to read a lot to make sure you are doing things exactly right.
Yes, I can. but it is simply inconvenient. And what is the actual reason of excluding a part of a headers from being sent thru FF debug console?

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

I believe the core issue is that certain headers are controlled by the platform and it overrides the values you enter in "edit and resend" and / or ignores custom values for them.

Not sure about Access-Control-Request-Method specifically, would need to look at more details to be sure.

Comment 11

[djFD]

honestly, as for me, I do not know what is "platform", the thing I did see is that certain headers are entirely stripped of some requests made via dev.tools

Just IMHO, if there is a panel to add some headers to a request, then it just have to do that without separating the the things by judging "allowed/disallowed for this request kind".

Unfortunately, right now it does not work. What can be simpler than just sending of 'forced' headers? It is devtools, is not it? I agreed, we can use a lot of the tools to send such requests, BUT e.g. for a quick testing of server side reaction to OPTIONS request when some headers do not match expected ones it much more convenient to do it from inside of the same dev tools box

As usually, we have two ways :D: wont'fix, need fix )