Content negotiation does not take into account media type parameters #963
Labels
t:marshalling
t:routing
Issues related to the routing DSL
t:server
Issues related to the HTTP server
Milestone
Comments
raboof
added a commit
to raboof/akka-http
that referenced
this issue
Mar 14, 2017
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 describes how to interpret the Accept header during content negotiation. Notably, it specifies "The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type", and then gives some examples. 'matching' is implemented in akka-http in `MediaRange::matches`, but for `MediaRange.One` fails to take into account parameters. 'precedence' is implemented in akka-http when determining the sorting of `acceptedMediaRanges` in `MediaTypeNegotiator`, but for non-wildcard media types sorts by the qValue instead of by the number of parameters.
jrudolph
added
3 - in progress
|
Hey @raboof, good to have you here ;) Thanks for tackling this. IIRC it was mentioned somewhere before but I cannot seem to find the place. |
raboof
added a commit
that referenced
this issue
Apr 13, 2017
* Use media type parameters in content negotiation (#963) https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 describes how to interpret the Accept header during content negotiation. Notably, it specifies "The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type", and then gives some examples. 'matching' is implemented in akka-http in `MediaRange::matches`, but for `MediaRange.One` and custom media ranges fails to take into account parameters. 'precedence' is implemented in akka-http when determining the sorting of `acceptedMediaRanges` in `MediaTypeNegotiator`, but for non-wildcard media types sorts only by the qValue ignoring the parameters. We do want to take into account the `qValue` when determining the order of `acceptedMediaRanges`, to make sure to select the right one when encountering a media type that matches multiple ranges with the same specificity but a different qValue. The specificity (number of parameters) should have precedence though.
|
Can we close this as solved? The linked PR had some minor questions but seems to fix this |
|
I think we just forgot to close. |
tomrf1
pushed a commit
to tomrf1/akka-http
that referenced
this issue
Aug 13, 2017
* Use media type parameters in content negotiation (akka#963) https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 describes how to interpret the Accept header during content negotiation. Notably, it specifies "The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type", and then gives some examples. 'matching' is implemented in akka-http in `MediaRange::matches`, but for `MediaRange.One` and custom media ranges fails to take into account parameters. 'precedence' is implemented in akka-http when determining the sorting of `acceptedMediaRanges` in `MediaTypeNegotiator`, but for non-wildcard media types sorts only by the qValue ignoring the parameters. We do want to take into account the `qValue` when determining the order of `acceptedMediaRanges`, to make sure to select the right one when encountering a media type that matches multiple ranges with the same specificity but a different qValue. The specificity (number of parameters) should have precedence though.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 describes how content negotiation should work when responding to requests with an
Acceptheader. The current implementation doesn't appear to take into account media type parameters.The text was updated successfully, but these errors were encountered: