Re: [XHR] test nitpicks: MIME type / charset requirements

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
> its value is a 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 thecharset 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<> may
> include MIME type parameters. [HTTP]<>

Of course, nothing is explicitely specified regarding the *response
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.

Please, correct me if I'm wrong and feel free to point me to the exact
sentences in the XHR spec that calls for an exception regarding
case-insensitivity of MIME types (as defined in HTTP which XHR references
through HTML 5.1). I may very well have missed those.


-- Julian

On 6 May 2013 19:22, Anne van Kesteren <> wrote:

> On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen
> <> wrote:
> > ...
> The reason the tests test that is because the specification requires
> exactly that. If you want to change the tests, you'd first have to
> change the specification. (What HTTP says on the matter is not
> relevant.)
> --

Received on Monday, 6 May 2013 22:45:28 UTC