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

Custom MediaType and MediaRange.matches are handled in a case sensitive way #2126

Closed
pzeppezauer opened this issue Jul 26, 2018 · 3 comments

Comments

@pzeppezauer
Copy link

commented Jul 26, 2018

Hi,

if I understand RFC 6838 correctly, both maintype and subtype of a MediaType should be case-insensitive.
This does not seem to work for custom media types in AKKA HTTP 10.1.3 (all tested in the scaladsl version but might apply to the java version too):

CommonActions.getMediaType converts both maintype and subtype to lower case using EnhancedString.toRootLowerCase

  1. In case we register the custom media type application/CUSTOM:
val `application/CUSTOM`: WithFixedCharset =
  MediaType.customWithFixedCharset("application", "CUSTOM", utf8)
val parserSettings = ParserSettings(system).withCustomMediaTypes(`application/CUSTOM`)
val serverSettings = ServerSettings(system).withParserSettings(parserSettings)

val routes = ...
val binding = Http().bindAndHandle(routes, host, port, settings = serverSettings)

ParserSettings.withCustomMediaTypes creates a case sensitive MediaTypes.FindCustom although the documentation of MediaTypes.FindCustom mentions that the input will be lower case.

The lookup for the custom media type in CommonActions.getMediaType (via CommonActions.customMediaTypes then does not work because it looks for ("application", "custom") which does not match the registered ("application", "CUSTOM").

as a fallback CommonActions then creates MediaType.customBinary("application", "custom", MediaType.Compressible, params = params, allowArbitrarySubtypes = true) using the lower case main- and subtype.

  1. In case we don't register it but only use it in a Unmarshaller or if the lookup above fails:

If we convert the media type application/CUSTOM (from the example above) to a ContentTypeRange and then use it in a Unmarshaller for specific content types (via Unmarshaller.EnhancedFromEntityUnmarshaller#forContentTypes) we face then another issue.

The media type is converted to a MediaRange.One(`application/CUSTOM`, 0f) (from the example above) which then does not match the media type application/custom created by CommonActions, because MediaRange.One.match compares both main- and subtype in a case sensitive way.

IMO there are 2 issues:

  • ParserSettings.withCustomMediaTypes should register the custom media type with lower case main- and subtype to conform to the scaladoc of MediaTypes.FindCustom.
  • MediaRange.One.match should make comparison of main- and subtype in a case insensitive way. The other implementations of MediaRange also seem to compare in a case sensitive way.
@ktoso

This comment has been minimized.

Copy link
Member

commented Jul 27, 2018

Hi there, I did not yet confirm this but agree that it should be case insensitive.
If you want to give fixing this a shot please do

@pzeppezauer

This comment has been minimized.

Copy link
Author

commented Aug 1, 2018

sure, I'll try to come up with a PR tonight

@jrudolph

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

Fixed by #2509.

@jrudolph jrudolph closed this Sep 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.