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

> > It seems strange the spec would require a case-sensitive value for

> > Content-Type in certain circumstances.

> 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.
> 

> 2. Require randomness.


We're discussing the case of a MIME type parameter sent from a client to a server, the question is basically where to draw the line between what we spec and what we leave up to the implementation. 


Currently, according to the spec the charset param is expected to be sent in lower case if the charset the JS sets matches (case insensitively!) the charset the implementation sends data in, and the JS used lower case (i.e. text/plain;charset=utf-8 will send charset=utf-8), in upper case if the implementation rewrites any charset parameter (text/plain;charset=foo => text/plain;charset=UTF-8 and perhaps least expected text/plain;charset=utf-8;charset=foo => text/plain;charset=UTF-8;charset=UTF-8). So per the spec itself the value may sometimes be lower cased, sometimes upper cased, and it may sometimes be transformed to upper case even if it was originally given in lower case.


We have no evidence that servers require or prefer a certain case. Servers (like Apache, IIS and Nginx) are generally written by professionals who understand case insensitivity. Server-side scripting, on the other hand, is not necessarily of high quality and might end up requiring a certain case. If such scripts exist, and if it's not documented what case is expected, we will end up with one of those small gotchas that are so harmful to cross-implementation compat. (On the other hand, if we already have a state where a variety of input is accepted and narrow down what is considered legal, content may well follow - this risks creating one of those backwards incompatibilities that annoy users with older devices and versions. IMO as spec authors we should also keep backwards compatibility in mind and not diverge from existing implementations unless we have good reasons.)


TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I do buy the argument that precision might cause better future compat, I'm however concerned about back compat and find it surprising that a strictly spec'ed implementation detail will sometimes transform the case the script actually used.



'HR
> 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 (if you're in
> bad luck you'll get mutual exclusive dependencies; the web has those
> too). E.g. the ordering of the members of the <canvas> element is one
> such thing (trivial bad luck example is User-Agent).
> 
> 
> --
> http://annevankesteren.nl/

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Tuesday, 7 May 2013 09:40:17 UTC