Re: [whatwg/fetch] CORS: arbitrary blocking of accept header based on length (#862)

@annevk The real problem here is that existing webapps randomly break because of this sudden strengthening of security. We can adjust servers (which we might not control) to set this header so whatever was working before now works again.

But what guarantees do we have that nothing works in the future?

We are working with open data, and all we want is to disable CORS protection. We don't need it, it doesn't apply to us, and we have other protection mechanisms in place. The trouble is that the previous "disable CORS protection" mechanism has now been broken, and that we do not have any mechanism that is guaranteed to be sustainable. We cannot beg servers every time to update.

Seems like what we want, and what I can imagine others also want, is a `Disable-CORS-Protection: true` header, where the server completely opts out of any browser-based security and rolls its own layer. I agree this is drastic, but there is a clear use case, and there are many alternatives for those who do want granular CORS control.

I will make a separate issue for this.

-- 
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/862#issuecomment-459384068