Parameter value case-sensitivity is media-type specific about negotiator

[dougwilson]

Hm, not sure. I believe the values used to be case-sensitive, but it seems the majority of the time they should have been case-insensitive, so it was swapped. I would rather play it by ear and wait for someone who has a legitimate want for them to be case-sensitive, otherwise re-evaluate before 1.0.

[dougwilson]

Reading this and read #35 it's basically sounding like doing any value matching on media type parameters is bound to be type-specific and cannot be done in a generic way. Does this sound right to you?

[ethanresnick]

I'm not sure. My hope is that we can do at least a bit better than that. See my comment on #35

[jasnell]

One particular case where case is significant is the profile attribute (see http://www.w3.org/TR/json-ld/#iana-considerations). The value of the profile attribute is URI. Comparison must always be done in a case-sensitive way (e.g. profile="http://example.org/#foo" is different than profile="http://example.org/#Foo")

[dougwilson]

I was just looking through the code to see when the value comparison was made case-insensitive, and it looks like it sneaked in in a4fafd8

I did a little digging, as if we were to pick case-sensitive vs. case-insensitive for media type parameter value matching, it seems like choosing case-sensitive is likely the most widely-applicable, with a big notable exception being the very common charset parameter, though it's odd to negotiate on this (as Accept-Charset exists for this, in general).

I really want to address this with a refactor that would make the point moot with a way to configure. Since there is no way to configure currently, it's very difficult to do a case-sensitive match.