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

On Fri, Oct 9, 2009 at 11:21 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Alex Russell wrote:
>>
>> Howdy,
>>
>> As you may have heard, Google Chrome Frame is a plugin that helps web
>> authors target modern standards and renderer features. The current
>> mechanism for this switch is a value for an http-equiv meta tag, the
>> same mechanism which IE 8 introduced for helping authors ensure
>> renderer-level compatibility for content. The GCF team plans to
>> support HTTP headers with the same values in the near future [1]. 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.
>>
>> 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.
>> ...
>
> 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.

Regards

Received on Friday, 9 October 2009 16:58:28 UTC