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>  
> 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  

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC