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!