Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaType parameters' values shouldn't be case-insensitive #49

Open
develop7 opened this issue May 8, 2024 · 1 comment
Open

MediaType parameters' values shouldn't be case-insensitive #49

develop7 opened this issue May 8, 2024 · 1 comment

Comments

@develop7
Copy link

develop7 commented May 8, 2024

Just yesterday I was reminded of subj. Instead, said parameters defined as (CI ByteString) as well as parameter names at

type Parameters = Map (CI ByteString) (CI ByteString)

Is this intentional? Because https://datatracker.ietf.org/doc/html/rfc7231#page-9 says otherwise IMO

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.

@zmthy
Copy link
Owner

zmthy commented May 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants