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
