jersey
  1. jersey
  2. JERSEY-1518

Request matching does not work correctly for MediaType with qs on a resource method

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Works as designed
    • Affects Version/s: 2.0-m09
    • Fix Version/s: 2.0-rc1, 2.0
    • Component/s: core
    • Labels:
      None

      Description

      @Path("resource/subresource/sub")
      public class AnotherSubResource {
      	@POST
      	@Consumes("text/*")
      	public String never() {
      		throw new WebApplicationException(Status.CONFLICT);
      	}
      
      	@POST
      	@Consumes("text/xml;qs=0.7")
      	public String xml() {
      		return MediaType.TEXT_XML;
      	}
      

      The method never is called for request:

      >> "POST /web/resource/subresource/sub HTTP/1.1[\r][\n]"
      >> "Content-Type: text/xml[\r][\n]"

        Activity

        Hide
        Marek Potociar added a comment -

        Note that the observed behavior is actually correct. During runtime, the effectively consumed media type is computed for both methods using the provided request content type (if not provided, MessageBodyReaders would be consulted) as follows:

        never() -> text/xml; q=1, qs=1
        xml() -> text/xml; q=1, qs=0.7
        

        Based on the computation above, the never() is selected. I'm going to close the issue as invalid. I ahve also added a test into Jersey E2E to cover this scenario.

        Show
        Marek Potociar added a comment - Note that the observed behavior is actually correct. During runtime, the effectively consumed media type is computed for both methods using the provided request content type (if not provided, MessageBodyReaders would be consulted) as follows: never() -> text/xml; q=1, qs=1 xml() -> text/xml; q=1, qs=0.7 Based on the computation above, the never() is selected. I'm going to close the issue as invalid. I ahve also added a test into Jersey E2E to cover this scenario.

          People

          • Assignee:
            Marek Potociar
            Reporter:
            jan.supol
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 3 hours
              3h
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 hour, 30 minutes Time Not Required
              1h 30m