On 2013-05-07 00:44, Julian Aubourg wrote:
Hey Anne,I don't quite get why you're saying HTTP is irrelevant. As an example, regarding the content-type /request /header, the XHR spec clearly states: If a |Content-Type| header is in author request headers <http://www.w3.org/TR/XMLHttpRequest/#author-request-headers> and its value is a valid MIME type <http://dev.w3.org/html5/spec/infrastructure.html#valid-mime-type> that has a |charset| parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the|charset| parameters of that |Content-Type| header to encoding. So, at least, the encoding in the request content-type is clearly stated as being case-insensitive. BTW, "Valid MIME type" leads to (HTML 5.1): A string is a valid MIME type if it matches the |media-type| rule defined in section 3.7 "Media Types" of RFC 2616. In particular, a valid MIME type <http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-mime-type> may include MIME type parameters. [HTTP] <http://www.w3.org/html/wg/drafts/html/master/iana.html#refsHTTP> Of course, nothing is explicitely specified regarding the /response /content-type, because it is implicitely covered by HTTP (seeing as the value is generated outside of the client -- except when using overrideMimeType). It's usage as defined by the XHR spec is irrelevant to the fact it is to be considered case-insensitively : any software or hardware along the network path is perfectly entitled to change the case of the Content-Type header because HTTP clearly states case does not matter. So, testing for a response Content-Type case-sensitively is /not /correct. Things are less clear to me when it comes to white spaces. I find HTTP quite evasive on the matter. ...
RFC 2616 is pretty clear if and only if you understand how "implied linear whitespace" works in it's version of ABNF.
In HTTPbis, we removed implied whitespace rules, so you may want to look at <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#media.type> instead (note that this is past WGLC and will be in IETF Last Call soonish). Best regards, Julian
