Re: CSR and Mozilla - Clarifying HTTP Header Filtering

Jonas:

Yes, the spec makes no mention of limiting HTTP Headers[1] - this is
what I expect. There is no limiting of values in the current
MLHttpRequest.setRequestHeader method and this, IMO, should continue
for the CRS version as well.

I've spent some time on this and I can't find any headers that should
be considered harmful in a CRS scenario. More to the point, I can't
see how CSR would 'make' any HTTP Header less safe, etc.

As has already been covered here, server still have the primary role
of enforcing access rights for all requests. Fiddling with the list of
allowed/disallowed HTTP Headers will not change that, right?

Maybe I am missing some scenario that has already been discussed where
HTTP Headers cause problems. Can anyone help me out on this?

Mike
[1] Header Field Definitions
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14)

On Feb 18, 2008 7:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> mike amundsen wrote:
> > I've read some threads that lead to me think that the Mozilla plan is
> > to block certain HTTP Headers in their implementation of CSR. I can't
> > find any details on this and would like some clarification.
> >
> > What, if any, HTTP Headers are going to be disallowed? Is this for all
> > HTTP Methods?
>
> First off, note that there are no particular headers disallowed when
> using the access-control spec in general. I.e. any headers normally sent
> with a request will be sent for cross-site requests that use the
> access-control spec.
>
> We do however limit which headers can be set using the
> XMLHttpRequest.setRequestHeader method. Looking at the code it currently
> only allows "accept" and "accept-language". Not actually sure what this
> very short list was based on. I do think we should at the very least
> also allow "content-type". If you have any further suggestions for
> headers that you think would be safe, do let me know.
>
> / Jonas
>



-- 
mca
http://amundsen.com/blog/

Received on Tuesday, 19 February 2008 03:11:42 UTC