Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

More intelligent Content-Type parsing #1660

Merged
merged 1 commit into from Nov 30, 2016

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Nov 30, 2016

Content-Type is allowed to contain options (; charset=utf-8, for
instance). We should allow that.

Content-Type is allowed to contain options (`; charset=utf-8`, for
instance). We should allow that.
@richvdh richvdh force-pushed the rav/better_content_type_validation branch from 3853ce2 to b5b3a7e Compare November 30, 2016 15:07
@NegativeMjark
Copy link
Contributor

I don't think the application/json mime-type has any parameters? But I guess people are silly enough to put parameters there, otherwise you probably wouldn't be making this PR. https://tools.ietf.org/html/rfc7159#section-11

LGTM if it works.

@richvdh richvdh merged commit 8379a74 into develop Nov 30, 2016
@richvdh richvdh deleted the rav/better_content_type_validation branch November 30, 2016 17:08
@kegsay
Copy link
Member

kegsay commented Dec 1, 2016

Though if you want to nitpick, the RFC does say:

Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.

In this case adding one does have an effect on the recipient :D

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

Successfully merging this pull request may close these issues.

None yet

3 participants