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

Since XHR is the API to facilitate a valid HTTP transaction, IMHO, it should be fully compliant with HTTP - no more and no less. A valid HTTP request and response should be interpreted consistently across UA's and devices.

Interoperability is very important across UA's and devices. If the XHR, either spec or implementation, is not fully compliant with HTTP, it will give users an unpleasant experience resulting from the interoperability issue.

-----Original Message-----
From: Charles McCathie Nevile [] 
Sent: Monday, May 06, 2013 6:06 PM
To: Julian Aubourg; Anne van Kesteren
Cc: Hallvord Reiar Michaelsen Steen; public-webapps WG
Subject: Re: [XHR] test nitpicks: MIME type / charset requirements

On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren <>  

> On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg <> wrote:
>> It seems strange the spec would require a case-sensitive value for
>> Content-Type in certain circumstances.  Are these deviations from the
>> case-insensitiveness of the header really necessary ? Are they  
>> beneficial for authors ?

"This is how the web is" rings like an 'argument from authority'. I'm  
generally less concerned about those than I believe you are, but I think  
Julien's questions here are important.

>> It seems to me they promote bad practice (case-sensitive testing of
>> Content-Type).
> There's only two things that seem to work well over a long period of
> time given multiple implementations and developers coding toward the
> dominant implementation (this describes the web).


> 1. Require the same from everyone.

So is there a concrete dominanant implementation that is case-sensitive?

Because requiring case-insensistive matching from everyone would seem to  
meet your requirement above, in principle. And it might even be that with  
good clear specifications and good test suites that the dominant  
implementation reinforces a simpler path for authors.

> Anything else is likely to lead some subset of developers to depend on
> certain things they really should not depend on and will force
> everyone to match the conventions of what they depend on

I know this has happened on the web for various cases. But it actually  
depends on having a sufficiently non-conformant implementation be  
sufficiently important to dominate (rather than be a known error case that  
is commonly monkey-patched until in a decade or so it just evaporates). I  
don't see any proof that it is *bound* to happen.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex         Find more at

Received on Tuesday, 7 May 2013 02:28:00 UTC