[whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Ian Hickson]

On Wed, 7 Oct 2009, Alex Russell wrote:
> 
> As currently specified, HTML 5 includes a list of pre-defined good 
> values for http-equiv [2] and specifies a pragma extensibility mechanism 
> [3] which predicates new entries on being registered HTTP headers from 
> duly submitted RFCs. This is onerous and does not fit well with current 
> network-level practice.

It is onerous intentionally; the idea is to reduce the use of this 
mechanism, as it has almost universally been misused.


> RFC 2616 [4], section 6.2 provides a mechanism for coordinating servers 
> and clients to use extensions:
> 
>    However, new or experimental header
>    fields MAY be given the semantics of
>    response-header fields if all parties in
>    the communication recognize them to
>    be response-header fields. Unrecognized
>    header fields are treated as entity-header
>    fields.
> 
> Server and client authors have used the "X-*" convention to denote such 
> extension fields as a forward-compatible prefix. In order for HTML 5 to 
> better represent real-world content, we'd like to request that an 
> exception be made to the "registered via RFC" rule for http-equiv 
> headers which are prefixed with "X-", or, alternately, that the spec 
> simply declare that unlisted keys and values will not be considered 
> invalid, but rather that only invalid values for listed keys trigger 
> validity errors.

This would make X-UA-Compatible conforming, which is not desireable. We 
want to _discourage_ mechanisms that lead to vendor-targetting of that 
nature.


On Fri, 9 Oct 2009, Maciej Stachowiak wrote:
> 
> HTML5 has a lot of extension points where, to make an extension valid, 
> you have to provide an open standard specifying its behavior. The idea 
> is that if you want something to be conforming, you have to specify it 
> well enough to allow interoperable implementations. The design of 
> X-UA-Compatible seems to make interoperability impractical. And I 
> suspect Microsoft has no interest in specifying it in the form of an 
> open standard. So making it noncomforming is serving the goals of the 
> spec, just as using proprietary elements or attributes is nonconforming. 

Indeed.


On Fri, 9 Oct 2009, Julian Reschke wrote:
> 
> But, there is a registration procedure, defined in RFC 3864. It defines 
> two registries, a provisional, and a permanent. The latter (and only 
> that) requires:
> 
>    Registration of a new message header field starts with construction
>    of a proposal that describes the syntax, semantics and intended use
>    of the field.  For entries in the Permanent Message Header Field
>    Registry, this proposal MUST be published as an RFC, or as an Open
>    Standard in the sense described by RFC 2026, section 7 [1].
> 
> (<http://tools.ietf.org/html/rfc3864#section-4.1>)
> 
> The HTML5 requirement goes further than the IETF requirement; I would 
> consider that a bug.

On Fri, 9 Oct 2009, Maciej Stachowiak wrote:
> 
> I think the HTML5 requirement should be changed to allow any header in 
> the Permanent Message Header Field Registry. Effectively, this would 
> require either an RFC or an Open Standard. This seems just as good for 
> HTML5's purposes as requiring an RFC.

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'