W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 09 Oct 2009 22:26:48 -0700
Message-ID: <8BA4AC31-824C-4E07-9C8D-D99F2AF9D2DA@apple.com>

On Oct 9, 2009, at 4:58 PM, Alex Russell wrote:

> On Fri, Oct 9, 2009 at 11:21 AM, Julian Reschke  
> <julian.reschke at gmx.de> wrote:
>>
>> True, but there is no real "X-" prefix convention for HTTP headers.
>>
>> 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.
>
> The more general point is that neither the spec nor the Validator
> doesn't seem to be savvy to any of this. The request that we observe
> the defacto "X-*" prefix is just a softer form of the general request
> that the spec should not call headers that it doesn't understand
> "invalid", casting documents that use them for compatibility reasons
> into invalidity purgatory. I'd strongly prefer that the spec were
> silent on un-specified values, noting instead that they should not
> cause a document to become invalid, rather than carving out special
> handling for one prefix.

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. You  
could question the goals, but they seem reasonable to me.

Regards,
Maciej
Received on Friday, 9 October 2009 22:26:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC