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

[Alex Russell]

On Sun, Oct 11, 2009 at 11:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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.

So just to clarify: should we standardize X-UA-Compatible at the IETF,
the validator would no longer complain about it, assuming that you'll
accept it in the wiki (which I'd like to be clear on)?

Regards