Re: XHR2 and Sec-* headers

Mark,

Your proposed approach makes sense to me.  It's reasonably easy to implement, and it's more broadly applicable since it doesn't rely on the form of the header field name.  My only suggestion would be that it might be more efficient to list the headers that *were* set by the script ("XHR2-Insecure").  That way you only incur complexity/bytes if something is actually changed, and you could just modify the setRequestHeader process to have that header field added to the XHR2-Insecure list (as opposed to starting with some master list and counting down).

Note also that this is not incompatible with the remainder of step 5; that would basically ensure that the listed headers never show up on the XHR2-Insecure list.  (OTOH, if you had XHR2-Insecure, you could imagine allowing scripts to change these headers, as long as they were flagged as insecure.)  And in any case, you will want to prevent scripts from setting the XHR2-Insecure header.

Anne's comment about this being in v1 should be read as a backward-compatibility challenge.  The danger, of course, being that a script in a v2 UA will set Sec- or Proxy- headers, which a v1 server will accept because it won't check the XHR2-Insecure header.  (I don't think there's a risk in the other direction, v1 UA to v2 server.)  I think the best that can be done in that regard is to RECOMMEND that scripts not be allowed to set Proxy- or Sec- headers and hope that there's not too many v1 servers out there relying on these headers being secure.  (As Anne's second email suggests.)

--Richard




On Feb 21, 2011, at 5:38 PM, Mark Nottingham wrote:

> W3C folk,
> 
> A HTTPbis WG member noticed that the XHR2 draft gives special status to HTTP headers starting with Sec-* and Proxy-*:
> 
> <http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method>
> 
> """
> Terminate these steps if header is a case-insensitive match for one of the following headers … or if the start of header is a case-insensitive match for Proxy- or Sec- (including when header is just Proxy- or Sec-).
> """
> 
> This really needs to be coordinated, for a few reasons.
> 
> First of all, this is a bit of a land grab. XHR2 is effectively reserving a name space in the range of possible HTTP header field names. Future applications with similar requirements will use this as precedence, and will mint their own header prefixes. When those prefixes need to be combined, we'll see fragmentation (e.g., the Sec-Private-Special-ID header, with all of the associated parsing and special handling of the field name that this entails).
> 
> Rather than name-spacing the headers, it would be much better to use an approach somewhat like the Connection header does; i.e., have the sender declare what headers it isn't allowing the client to modify in a separate header. E.g.,
> 
> XHR2-Secure: Foo, Bar, Baz
> 
> Secondly, if this approach *were* to go forward, we'd need to reflect this practice in the registration procedure for message headers (RFC3864) and HTTP specification (RFC2616, currently under revision in the HTTPbis WG).
> 
> I've raised this as a comment to the WG, and I'd like to discuss it briefly on our upcoming call.
> 
> Regards,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
>

Received on Tuesday, 22 February 2011 16:00:30 UTC