Minor Description
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.
Attachments
Issue Links
- links to