Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-2874

Web Target Proxy not overriding content type header

    XMLWordPrintable

Details

    • Hide

      I have outlined a basic example in this Gist showing the behaviour. 

      Issue part 1: Content-Type on request

      Steps:

      1. Create a simple JAX-RS annotated resource
      2. Create a POST endpoint that takes a content type header param and some content and consumes multiple mime types.
      3. Using ResteasyClientBuilder build a client and subsequent  ResteasyWebTarget.proxy(Class) create a proxied client for the resource
      4. Invoke the resource passing the content type header param

      Result:

      The default (first) header param on the @Consumes annotation will be sent to the server, instead of the user provided type.

      Issue part 2: Content-Type in ClientRequestContext

      1. Steps:
        Follow the steps for part 1 but register a ClientRequestFilter in your ClientBuilder
      2. Invoke the resource passing the content type header param

      Result

      Inside ClientRequestFilter.filter(ClientRequestContext) the ClientRequestContext will only contain a single header first in the list, the header from the @Consumes annotation on your proxied resource. However, if you pass you params the other way round, the collection will contain both headers...

      // client filter will only contain one header.
       doPost(@HeaderParam("Content-Type) String contentType, byte[] content);
      // client filter will contain two headers.
       doPost(byte[] content, @HeaderParam("Content-Type) String contentType);
      

       

      This feels inconsistent, if not a bug, is there any clarification on the expected behaviour?

      Show
      I have outlined a basic example in this Gist  showing the behaviour.  Issue part 1: Content-Type on request Steps: Create a simple JAX-RS annotated resource Create a POST endpoint that takes a content type header param and some content and consumes multiple mime types. Using ResteasyClientBuilder build a client and subsequent  ResteasyWebTarget.proxy(Class) create a proxied client for the resource Invoke the resource passing the content type header param Result: The default (first) header param on the @Consumes annotation will be sent to the server, instead of the user provided type. Issue part 2: Content-Type in ClientRequestContext Steps: Follow the steps for part 1 but register a ClientRequestFilter in your ClientBuilder Invoke the resource passing the content type header param Result Inside ClientRequestFilter.filter(ClientRequestContext) the ClientRequestContext will only contain a single header first in the list, the header from the @Consumes annotation on your proxied resource. However, if you pass you params the other way round, the collection will contain both headers... // client filter will only contain one header. doPost(@HeaderParam("Content-Type) String contentType, byte [] content); // client filter will contain two headers. doPost( byte [] content, @HeaderParam("Content-Type) String contentType);   This feels inconsistent, if not a bug, is there any clarification on the expected behaviour?
    • Documentation (Ref Guide, User Guide, etc.), User Experience
    • Undefined

    Description

      When invoking requests via a proxied client of T created via org.jboss.resteasy.client.jaxrs.ResteasyWebTarget#proxy(Class) the behaviour of mime types for javax.ws.rs.HeaderParam("Content-Type") seems inconsistent.

      If I have a resource that can consume multiple mime types I would expect to be able to pass a type into my proxied client via a header param and have that type favoured in negotiation.

      I have attempted to work around this with client filters which also experience some interesting behaviour that I was not able to find documented.

       

      https://gist.github.com/tcooper-uk/70407fcf3ea4a3b9a811470b06d37d71

      Attachments

        Issue Links

          Activity

            People

              pberan@redhat.com Petr Beran
              tcooper.uk Tom Cooper (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: