[
https://issues.apache.org/jira/browse/CXF-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244542#comment-16244542
]
ASF GitHub Bot commented on CXF-7553:
-------------------------------------
andymc12 opened a new pull request #335: [CXF-7553] Consider the req headers'
quality factors in selectVariant
URL: https://github.com/apache/cxf/pull/335
The Request.selectVariant method should return one of the passed-in Variants
that is closest to the variant (combination of Accept, Accept-Language and
Accept-Encoding headers with quality factors included).
This bug was first reported in CXF 3.1.11, so I'll plan to fix it in
3.1.x-fixes first - and after proper review, I'll make the same change in 3.2.X
(master).
Please see the [JIRA](https://issues.apache.org/jira/browse/CXF-7553) for
more details of the issue in question - I'm looking for confirmation that this
is the appropriate spec-defined behavior (the spec and JAX-RS javadoc is a
little ambiguous here) and that this is the best way to fix it.
Thanks, Andy
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> selectVariant doesn't take into account quality factors in Accept header
> ------------------------------------------------------------------------
>
> Key: CXF-7553
> URL: https://issues.apache.org/jira/browse/CXF-7553
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.14, 3.2.1
> Reporter: Andy McCright
> Priority: Minor
> Fix For: 3.1.15, 3.2.2
>
>
> We've got a customer moving from Apache Wink (JAX-RS 1.1) to CXF 3.1.X
> (JAX-RS 2.0) and they are seeing subtle differences in the behavior of the
> javax.ws.rs.core.Request.selectVariant method. According to the spec, the
> returned Variant should be one of the Variants passed in to the selectVariant
> method that is the closest match to the request (based not the Accept,
> Accept-Language, and Accept-Encoding headers). They see this behavior in
> Wink, but in CXF, they see that the first Variant in the passed-in list that
> matches the request's headers is chosen.
> For example, a request with "Accept: a/b, c/d; q=0.5" will return a response
> with "Content-Type: a/b" - assuming that the resource method produces a/b and
> c/d. However, when the user calls:
> List<Variant> list = new ArrayList<Variant>();
> Variant v1 = new Variant("a/b", (Locale) null, null);
> Variant v2 = new Variant("c/d", (Locale) null, null);
> Variant v3 = new Variant("not/used", (Locale) null, null);
> list.add(v3);
> list.add(v2);
> list.add(v1);
> assertSame(v1, Request.selectVariant(list));
> the assertion fails. Even though the user prefers a/b over c/d by a quality
> factor of 1 vs 0.5, the selectVariant method returns the Variant with c/d.
> This is because the RequestImpl's implementation of the selectVariant method
> only checks the request headers when intersecting the Mime (Media)Types.
> To match Wink's implementation (and my understanding of the spec, though to
> be fair, the spec is somewhat ambiguous...), I think CXF should take the
> request header's quality factors into account when determining which Variant
> to return.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
