Details
-
Bug
-
Resolution: Done
-
Major
-
1.2.1.GA
-
None
Description
Section 3.8 of the JAX-RS Spec (I was looking at 1.0) is titled "Determining the MediaType of Responses" and outlines a specific Algorithm (page 18) for how to determine the current MediaType in order to select a method in a Resource.
Part of the Algorithm requires that one intersects the set P of producable media types (step 2) with the set A of accepted media types (step 4) from the HTTP Accept Header to get set M. Set M is then sorted in descending order ased on the specificity and q-value of each media type. RESTEasy is not properly implementing this algorithm.
It appears to be failing to properly intersect set M to remove media types that are not producable (ie in set P).
For example, a resource has a message body writer that produces "application/xml" and a request is sent in with an Accept header "text/html, application/xml" then it fails to find a message body writer and throws a 500 response code. When the order is switched to "application/xml, text/html" it works.
Similarly, if the Accept header is "application/xml;q=0.7, text/html;q=0.8" then a 500 is thrown with an error stating that no message body writer can be found. But if Accept: "application/xml;q=0.8, text/html;q=0.7" or Accept: "application/xml, text/html" then the proper message body writer is located and the request successfully completes.
Note that the Resource in question here does not have an @Produces annotation. It has a return type X and a message body writer that @Produces application/xml and accepts type X for producing it.
So it seems that RESTEasy is not sorting out the "unproducable" types when creating the set M. Thanks for looking into it!