[whatwg] X-UA-Compatible, X-* headers, validators, etc.
Ian Hickson
ian at hixie.ch
Sun Oct 11 23:39:47 PDT 2009
On Wed, 7 Oct 2009, Alex Russell wrote:
>
> 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.
It is onerous intentionally; the idea is to reduce the use of this
mechanism, as it has almost universally been misused.
> 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.
This would make X-UA-Compatible conforming, which is not desireable. We
want to _discourage_ mechanisms that lead to vendor-targetting of that
nature.
On Fri, 9 Oct 2009, Maciej Stachowiak wrote:
>
> 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.
Indeed.
On Fri, 9 Oct 2009, Julian Reschke wrote:
>
> 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.
On Fri, 9 Oct 2009, Maciej Stachowiak wrote:
>
> I think the HTML5 requirement should be changed to allow any header in
> the Permanent Message Header Field Registry. Effectively, this would
> require either an RFC or an Open Standard. This seems just as good for
> HTML5's purposes as requiring an RFC.
Done.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list