On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes <rbar...@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/
