[sorry if this is a repeat, sent first copy in the process of joining the list]
Jumping over to this list (hi, I'm new here!) from another list. To recap: I had chimed in in support of Mark's proposal, and Anne said "It fails to meet the goal of Sec-", with a pointer to this thread. It seems like the high-level requirement is for the recipient of an HTTP request to know which parts of the request are "secure", in the sense that they were set by the UA, and which are "insecure", in the sense that they are, or may have been, set by a script. Presumably the entity-body is always insecure, so we're confined to header fields. The current XHR and XHR2 specs satisfy this requirement by means of an enumeration of headers plus a prefix. Any header name in the enumeration, or starting with the prefix, is secure, otherwise it's insecure. As Mark noted, this deals poorly with extensibility, since any new secure headers have to go in the "Sec-*" prefix. This is especially problematic if a UA wants to protect some standard field beyond the enumeration (say, X-Forwarded-For), or if there is some other convention that calls for a different prefix. 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. --Richard
