- From: Alex Russell <slightlyoff@chromium.org>
- Date: Wed, 7 Oct 2009 11:01:13 -0700
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
Received on Wednesday, 7 October 2009 11:01:13 UTC