Why isn’t fetch sending ORIGIN header in CORS mode?

Question

Like everyone else who attempts it, I am having trouble getting CORS to work. My code is as follows:

fetch(url, {
      mode: 'cors',
      cache: 'no-cache',
      method: 'post',
      credentials: 'include',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(body),
    });

Regardless of the URL, I do not get the origin header of the request showing in Chrome’s Network tab.

And (“correctly”) the request fails with as CORS Error.

The method header isn’t there either, but I don’t know if that is part of the problem.

(Enragingly, this seems to work on Safari.)

See: https://stackoverflow.com/questions/21177387/caution-provisional-headers-are-shown-in-chrome-debugger — , Apr 08 '21 at 00:26
So this is a `POST` and requires preflighting if it is cross-domain i.e. `fetch` should be sending an `OPTIONS` request before making the post... Is it? You're also setting `credentials: 'include'` which piles on yet [more limitations](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflight_requests_and_credentials). Are you sure you're ticking all the boxes? — spender, Apr 08 '21 at 00:31
@spender — it is only sending the one request, no pre-flight, so does that mean that it does not realize it is supposed to be POST? I am sure I am **not** ticking all the boxes, because it doesn’t work, but I don’t know which ones I missed. — Michael Lorton, Apr 08 '21 at 01:22
@stringy05 — it is only sending the one request, no pre-flight. Arrgggh. — Michael Lorton, Apr 08 '21 at 01:22

score -1 · Answer 1 · answered Apr 08 '21 at 02:02

-1

It was Amy who actually answered this.

The underlying problem is: the server is misconfigured. I knew that and I was waiting for the server-guy to fix it. In the meanwhile, I was trying to get the client side to work.

But, since I was getting bad headers back, Chrome decided to... well, act up, and only show “provisional” headers — which did not, for whatever reason, include the Origin header.

When Safari “worked”, it only worked in the sense of giving a sensible error response (“Not getting the right CORS headers back from the server”). I don’t know what is keeping Chrome from doing this.

To figure this out, I had to download and learn Wireshark, then I had to make changes to some Bush-era Tomcat code under IntelliJ. Arrrgghhh.

answered Apr 08 '21 at 02:02

Michael Lorton

43,060
26
103
144

1

try this: set chrome://flags/#out-of-blink-cors to disable, this should make Chrome display the pre-flight in the network tab. – stringy05 Apr 08 '21 at 02:05
2

Yeah, whenever I see the "provisional headers" thing, I switch to Fiddler. It's the only way to see what's happening on the wire. – Apr 08 '21 at 02:07
Yes. [Fiddler](https://www.telerik.com/fiddler) or [Charles](https://www.charlesproxy.com/) are somewhat higher level means of doing this analysis and preferable to using WireShark. – spender Apr 09 '21 at 16:24
@spender — thanks, I found WireShark to be fairly... gritty. – Michael Lorton Apr 09 '21 at 16:26
Yeh. It's overqualified for the job :) – spender Apr 09 '21 at 16:49

Why isn’t fetch sending ORIGIN header in CORS mode?

1 Answers1