Re: [XHR2] Feedback on sec-* headers

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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 24 February 2011 11:54:15 UTC