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
