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

resteasy.client.core.ClientMarshallerFactory's incorrectly url encodes when working wiht PathParam, Encoded annotations.

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 1.0.1.GA
    • Fix Version/s: 1.1.RC1
    • Component/s: None
    • Environment:

      java 6, tomcat 6, resteasy 1.0.1.GA, spring 2.5.6 (resteasy used with spring mvc integration)

      Description

      resteasy.client.core.ClientMarshallerFactory is making different decisions if the target PathParam annotated parameter is Encoded annotated or not. The current implementations seems to work buggy because of this. Imho from the client point of view Encoded shouldn't make any difference.

      Suggested change in resteasy.client.core.ClientMarshallerFactory:
      isEncoded variable is not needed. The following two lines could be deleted:
      boolean isEncoded = FindAnnotation.findAnnotation(annotations,
      Encoded.class) != null;
      PathParamMarshaller should be instantiated with contant true. Instead of
      marshaller = new PathParamMarshaller(uriParam.value(), isEncoded,
      providerFactory);
      should be:
      marshaller = new PathParamMarshaller(uriParam.value(), true,
      providerFactory);

      The problem by which I encountered this problem.
      Have an Echo interface:
      @Path("/rest/echo")
      public interface Echo {

      @GET
      @Path("string/

      {message}

      ")
      @Produces(MediaType.TEXT_PLAIN)
      public String echoString(@PathParam("message") String message);
      }
      and an EchoImpl implementing it:
      public class EchoImpl implements Echo {
      private Logger logger = LoggerFactory.getLogger(EchoImpl.class);

      public String echoString(String message) {
      logger.debug("started message = {}", message);
      return message;
      }
      }

      If I call "/rest/echo/string/hello world" from browser I can see the server receiving a request to "/rest/echo/string/hello%20world" (space url encoded). Resteasy decodes it (correctly because no Encoded annotation presented) and so message variable holds the decoded value "hello world". Everything works correctly the browser gets the correct return value back.

      However I have the following unit test:
      public class TestEchoClient {
      private Echo echoClient;
      private Echo echo;

      @Before
      public void setUp() throws Exception

      { RegisterBuiltin.register(ResteasyProviderFactory.getInstance()); echoClient = ProxyFactory.create(Echo.class, "http://localhost:8888/resteasy01_echo"); echo = new EchoImpl(); }

      @After
      public void tearDown() throws Exception {
      }

      @Test
      public void testEchoString()

      { String message = "hello world"; assertEquals("Transfer error.", echo.echoString(message), echoClient.echoString(message)); }

      }

      If I run this I see on the server a request for "/rest/echo/string/hello%2520world" (it seems as the message got encoded twice), message variable will hold "hello%20world" (decoded once) and so the returned value will be incorrect and the test fails.

      If I add @Encoded to message parameter in Echo the correct return value will be "hello%20world" (and thats what I see in the browser) and using the unit test now the client does not double encodes the input (request url will be "/rest/echo/string/hello%20world") and the unit test also returns "hello%20world" as the browser.
      Imho this should be the behaviour without the Encoded annotations too. If I change ClientMarshallerFactory as mentioned above I get the good result without Encoded too.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                bill.burke Bill Burke
                Reporter:
                akiraly Attila Király
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: