All POST fetch requests in browser window have Origin: 'null' in headers

[karelbilek]

• Electron version: 1.4.5
• Operating system: Ubuntu + OS X

Expected behavior

I use fetch API with method: 'POST' in the browser window and it has something sensible in 'origin' header.

Actual behavior

I use fetch API with method: 'POST' in the browser window and it has the string 'null' in 'origin' header.

How to reproduce

I cloned electron-quick-start for a simple repro here (diff)

I do a simple request to https://www.example.org 1 second after start (so that the dev tools see it).

When you click on the example.org request and scroll down, you can see the 'origin: null'

I also added logging of headers in the main thread, so you can see that the 'null' is indeed a string (and not "javascript null").

{ Accept: '*/*',
  'Accept-Encoding': 'gzip, deflate',
  'Accept-Language': 'en-US',
  Origin: 'null',
  'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) electron-quick-start/1.0.0 Chrome/53.0.2785.113 Electron/1.4.5 Safari/537.36',
  'X-DevTools-Emulate-Network-Conditions-Client-Id': '5934e521-44cd-4ca2-bccc-023c044c93a8' }

Removing {method: 'POST'} causes the Origin: 'null' to go away

Notes

This might actually be a good behavior; however, I want to know why exactly that happens. What is the spec, what is the reasoning behind it. Is it a bug or a feature?

I found some references to string 'null' here

• https://www.w3.org/TR/cors
• https://tools.ietf.org/html/rfc6454#section-6.2

Particularly in the second link

The ascii-serialization of an origin is the value returned by the following algorithm:

1. If the origin is not a scheme/host/port triple, then return the string null

(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.

[MarshallOfSound]

I would also like to know why it is inconsistent with a GET request. If you send a GET request with the same code it will simply not have an origin header at all (somewhat expected it's a file:// uri). It's the inconsistency that throws me more than anything else 😕

[deepak1556]

I would also like to know why it is inconsistent with a GET request

This issue was raised sometime back, you can find the reason why no origin header is sent for cors GET request here from file scheme.

What is the spec, what is the reasoning behind it. Is it a bug or a feature?

The fetch spec allows origin header when sending POST request, which you can find here .

Closing this out, since its the expected behavior in Electron. You can use custom protocols for this scenario.

[karelbilek]

I am sorry, I still don't understand this.

• Why is GET and POST treated differently? I cannot find it in the thread.
• Where does the null string come from? I don't know how to interpret it. Why is it null specifically and not some "actual" origin?

Thanks!

[karelbilek]

(I am hoping to understand this so I know why Electron behaves the way it behaves, and also to help other people who will maybe find this issue by google :))

[deepak1556]

Why is GET and POST treated differently? I cannot find it in the thread.

For both the requests origin will not be set initially, as they are treated as same origin requests because of the reason specified in the above linked thread. But just before the request is sent blink sets the origin for non-get and non-head requests here. Hence you see the different behavior.

Where does the null string come from? I don't know how to interpret it. Why is it null specifically and not some "actual" origin?

The value is set by blink, the reason for null is related to the securityorigin value.

[karelbilek]

Thanks! That's what I needed to know.

[intellix]

I've got around this by doing:

electron.session.defaultSession.webRequest.onBeforeSendHeaders((details, callback) => {
  details.requestHeaders['Origin'] = 'electron://graphiql-app';
  callback({ cancel: false, requestHeaders: details.requestHeaders });
});

[andreiglingeanu]

Managed to get around this (in the context of a web extension though) by conditionally removing Origin header in onBeforeSendHeaders handler.

[SmadusankaB]

Run your app on a (local) server (like wamp, xampp, mamp)

[ghost]

@deepak1556

But just before the request is sent blink sets the origin for non-get and non-head requests here.

why is the origin header not set for head request ?
any workaround for this ??

[davidsth]

This still isn't fixed yet. We had to follow instructions from @intellix 's instructions.

[kimseonguk197]

I am sorry, I still don't understand this.

• Why is GET and POST treated differently? I cannot find it in the thread.
• Where does the null string come from? I don't know how to interpret it. Why is it null specifically and not some "actual" origin?

Thanks!

this issue is long time ago issue, but I recently found some resources heer. in 414 line you can find that chrome send origin header when it is blank without 'get' or 'head' method