W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [XHR2] Feedback on sec-* headers

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 24 Feb 2011 12:53:37 +0100
To: public-webapps@w3.org, "Richard L. Barnes" <rbarnes@bbn.com>
Message-ID: <op.vreonnej64w2qv@anne-van-kesterens-macbook-pro.local>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT