On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: > 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.
Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. --Richard
