- From: Ruben Verborgh <notifications@github.com>
- Date: Fri, 24 Jun 2016 09:50:24 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc:
- Message-ID: <whatwg/fetch/issues/326/228398863@github.com>
> It's vastly unclear what is safe to do here and what is unsafe so we error on the side of caution. That's the wise approach indeed. However, it could be worthwhile re-evaluating the list, as from what I understand, its members were selected without a clear process. For instance, we could find a list of headers that are definitely unsafe (e.g., `X-HTTP-Method-Override`), headers that are definitely safe (e.g., `Accept`), headers that require investigation. > we can add more same-origin policy exemptions over time is not workable. The list should not keep on growing of course. But perhaps a study of what is allowed now and in the future could be timely, given that it is currently “vastly unclear what is safe”. > Perhaps there is a prefix we can agree on that is the opposite of `Sec-` But then we're building custom one-offs for the browser only… there's other HTTP clients. ------ Looking up `Sec-`, I noticed that `Accept-Charset` and `Accept-Encoding` are also in the [list of forbidden header names](https://fetch.spec.whatwg.org/#forbidden-header-name). This of course makes sense, and now I understand better why `Accept- *`might seem undesired. However, at the same time, I wonder what the consequences can be from using other `Accept-Charset` and `Accept-Encoding` than what the browser would do (other than the browser not being able to interpret the response). So that's perhaps also something to be studied: for each header, what are the negative consequences of (dis-)allowing it. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/326#issuecomment-228398863
Received on Friday, 24 June 2016 16:50:59 UTC