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