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

[Alex Russell]

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.

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.

Regards

[1] http://code.google.com/p/chromium/issues/detail?id=22802
[2] http://www.whatwg.org/specs/web-apps/current-work/#attr-meta-http-equiv
[3] http://wiki.whatwg.org/wiki/PragmaExtensions
[4] http://www.ietf.org/rfc/rfc2616.txt