Re: Cross-site Requests and Custom HTTP Headers

Anne van Kesteren wrote:
> 
> I thought I'd outline my proposal for custom HTTP headers in a separate 
> thread as the other threads had lots of noise. We change the cross-site 
> request algorithm in the Access Control specification slightly to take a 
> list of author provided HTTP headers. These author provided HTTP headers 
> are filtered against a blacklist BL and then checked against a whitelist 
> WL.
> 
> BL is the list of headers currently listed in the XMLHttpRequest 
> specification under the setRequestHeader() algorithm with the addition 
> of cookie and credentials headers.
> 
> WL is Accept, Accept-Language, and any other headers that we think fit 
> here.
> 
> We also name the "cross-site GET access request" algorithm the 
> "cross-site default access request" algorithm and the "cross-site 
> non-GET access request" algorithm the "cross-site access request with 
> preflight" algorithm. (Or something equivalent.)
> 
> Then if the desired request uses the HTTP GET method and checks 
> positively against the whitelist WL (no other headers are included) the 
> cross-site default access request algorithm is used. Otherwise the 
> cross-site access request with preflight algorithm is used.
> 
> This means that cross-site GET requests with custom HTTP headers other 
> than Accept and Accept-Language will also get a preflight (but are not 
> prohibited) and that all the other HTTP methods will work as they do in 
> the current proposal except that there header list is not restricted.

So this means that we're saying that if the server sends a response like

Access-Control: allow <*>

to an OPTIONS request, the server should be prepared to handle requests 
that contain *any* user set header? I know we've talked about having 
another header in the reply to the OPTIONS request that specified which 
headers would be allowed. This would make me feel safer to be honest.

/ Jonas