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

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.

BR, Julian

Received on Friday, 9 October 2009 11:21:14 UTC