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
