Re: [whatwg/fetch] CORS-safelisted request-headers and Client Hints (#1006)

@martinthomson I suspect that Origin Policy would work as well; while you pay a RTT for the first request, it's cacheable and origin-wide (unlike OPTIONS). For video, that's probably wearable. On h2+, you could even do a parallel OP request to the initial OPTIONS, possibly triggered by an OPTIONS response header.

Or is there another reason you're considering a TLS extension (which is much harder to deploy - but maybe that's what you're wanting)?

@annevk your response to my suggestions leaves me wondering about the threat model and the browsers' place in addressing it. A server that changes its behaviour based upon a new header that it defines takes on the responsibility for assuring that it's not vulnerable; browsers aren't assumed to protect them from everything. CORS was put in place because of vulnerabilities exposed at scale by XHR and friends, it's not a general solution to securing servers.

To put it another way - a server can be tricked if the URL query string contains data that it doesn't anticipate, and yet browsers have gone off and allowed any old query string in requests. _How could you?_


-- 
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/1006#issuecomment-606400355