Forbidden headers can’t be set in "fetch" requests (#tilPost)

Here's Alex blogging about forbidden request headers. Forbidden what? Exactly!

It turns out that when using the fetch API (or if you're old school, XMLHttpRequest) there's a set of headers that you can't specify or overwrite from within JavaScript.

The spec defines three different types of forbidden request headers.

First, all headers in this list are forbidden:

• Accept-Charset
• Accept-Encoding
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Connection
• Content-Length
• Cookie
• Cookie2 (This seems to be a deprecated spec that never went anywhere)
• Date
• DNT
• Expect
• Host
• Keep-Alive
• Origin
• Referer
• Set-Cookie
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• Via

Second, headers starting with proxy- or sec- are also forbidden.

And third, if there's something going on with the parsed values of the headers X-HTTP-Method, X-HTTP-Method-Override, and X-Method-Override header they might be forbidden, too.

Apparently, you can overwrite or at least signal that the initial HTTP method should be a different one? I have so many questions, but I'll leave them for another time.

So, what happens if you try to set a forbidden header?

fetch('https://api.example.com/data', {
  headers: {
    'Content-Length': '100',  // This will be ignored
    'X-Custom-Header': 'This is fine'  // This will be sent
  }
})

Browsers will simply ignore them and maybe, if they're kind, log a warning.

This all makes sense because the spec states that there should be things the user agent remains in control of.

These are forbidden so the user agent remains in full control over them.

This behavior makes total sense to avoid nasty security loopholes. I can imagine that if JavaScript could overwrite every header it would open all kinds of security vulnerability doors.

If you want to dive deeper check out Alex's post, it's a nice one.