3

Today, I wanted to utilize the Accept-Encoding header to request an image as base64. Come to find out, the XMLHttpRequest spec prevents setting that header!

http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader()-method

Note: The above headers are controlled by the user agent to let it control those aspects of transport. This guarantees data integrity to some extent. Header names starting with Sec- are not allowed to be set to allow new headers to be minted that are guaranteed not to come from XMLHttpRequest.

Why in the world would they write a spec like this? It'd make more sense if the browser just provided a default value (eg. gzip,deflate,sdch) if none was specified.

Stephen Bunch
  • 327
  • 4
  • 15

2 Answers2

4

The browser is responsible for accepting and processing the response. It wouldn't make much sense to manipulate your XHR to say it accepts gzip, for example, when you couldn't do anything with it. Can you just set a custom header value?

Matt Pileggi
  • 7,126
  • 4
  • 16
  • 18
  • Thanks! I was hoping there was a better reason, but I suppose that makes sense. – Stephen Bunch Mar 13 '14 at 22:13
  • 2
    ^ This is exactly what I'm bumping my head against now. :( – eltiare Dec 12 '16 at 20:09
  • Problem is that the server sometimes is misbehaving and thinks the content is gzip when it's not, and then sets Content-Encoding:gzip header, and then the browser "which is responsible for processing the response" erroneously unzips it causing errors – Colin D Mar 22 '17 at 15:30
0

Why in the world would they write a spec like this?

In one word: laziness.

Why add in extra semantics describing secure predictable browser behavior for every possible header that would only be used by a few people like us, when they can just declare all the headers prohibited in one paragraph.

user3338098
  • 907
  • 1
  • 17
  • 38