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

On 2013-05-07 11:39, Hallvord Reiar Michaelsen Steen wrote:
>>> 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.
> ...

Indeed. See also 
<http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0955.html> about 
the requirement to rewrite charset parameters in-place, and - slightly 
related - <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15312> about 
the requirement to lowercase header field names in CORS.

Best regards, Julian

Received on Tuesday, 7 May 2013 13:17:10 UTC