Re: [XHR2] Feedback on sec-* headers

On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote:

> On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes <rbarnes@bbn.com> wrote:
>> Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to).  Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure.  This allows any header to be marked as secure, regardless of its name.
>> 
>> It's also arguably easier to implement:
>> 1. On the sending side:
>> 1.curr. Check membership in a fixed enum || prefix
>> 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum)
>> 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum
>> 2. On the receiving side:
>> 2.curr. Check membership in a fixed enum || prefix
>> 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum
>> 
>> The major concern is backward compatibility.  I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns.  But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum.
> 
> Would this not mean that for each new header introduced servers would have to check an "XHR2-secure" header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid.

Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration.  So it's just a question of how you check, set containment vs. prefix match.  I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant.

--Richard

Received on Thursday, 24 February 2011 15:59:44 UTC