You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The type, subtype, and parameter name tokens are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name.
The text was updated successfully, but these errors were encountered:
I don't remember if it was intentional, but if it was it was probably a practical concession that the ones that most users are going to care about (probably just charset) are case insensitive. The paragraph following the one you've quoted uses an example where the value is case insensitive. We seem to have made the same assumption in implementing the Accept class for ByteString, where we perform a case-insensitive equality check.
If it's just a representation problem, then arguably you can access the original string with CI.original, but perhaps a better approach would be to drop the CI wrapping and update the code for matches to do a case insensitive comparison. If you want to be able to match parameter values with case sensitivity, then we need to come up with a way for the client code to specify whether a parameter value is case sensitive or not.
Just yesterday I was reminded of subj. Instead, said parameters defined as
(CI ByteString)
as well as parameter names athttp-media/src/Network/HTTP/Media/MediaType/Internal.hs
Line 87 in 5db8b78
Is this intentional? Because https://datatracker.ietf.org/doc/html/rfc7231#page-9 says otherwise IMO
The text was updated successfully, but these errors were encountered: