Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-4737

Camel netty-http consumer endpoint incorrectly decodes URIs when bridging endpoints

XMLWordPrintable

    • % %
    • Hide

      1. Execute the following Camel route in any environment, under Camel 2.15.1:

        from("netty-http:http://localhost:9000/camel?matchOnUriPrefix=true")
          .to ("http4://localhost:9000/fred?bridgeEndpoint=true");

      2. Monitor the HTTP traffic to port 9000, e.g., using tcpdump or WireShark
      3. Using any HTTP client (e.g., wget) make this HTTP GET request:

      http://localhost:9000/camel/x=%3B

      4. Note that the GET request that actually gets forwarded to the "to" URI is:

      http://localhost:9000/camel/x=;

      5. Replace the netty-http endpoint with a jetty endpoint, and repeat. Note that the URI remains in its encoded form when passed to the destination.

      I suggest using a network trace here, rather than some form of logging in Camel, because Camel itself might manipulate the URI and therefore obscure the problem. Tracing the network data makes it very clear that the GET request is incorrect.

      Show
      1. Execute the following Camel route in any environment, under Camel 2.15.1: from( "netty-http:http: //localhost:9000/camel?matchOnUriPrefix= true " ) .to ( "http4: //localhost:9000/fred?bridgeEndpoint= true " ); 2. Monitor the HTTP traffic to port 9000, e.g., using tcpdump or WireShark 3. Using any HTTP client (e.g., wget) make this HTTP GET request: http://localhost:9000/camel/x=%3B 4. Note that the GET request that actually gets forwarded to the "to" URI is: http://localhost:9000/camel/x= ; 5. Replace the netty-http endpoint with a jetty endpoint, and repeat. Note that the URI remains in its encoded form when passed to the destination. I suggest using a network trace here, rather than some form of logging in Camel, because Camel itself might manipulate the URI and therefore obscure the problem. Tracing the network data makes it very clear that the GET request is incorrect.
    • 6.3 Sprint 3 (Feb 29 - Mar 25)

      A Camel application routes HTTP requests between HTTP clients and servers using rules that are defined programatically. netty-http endpoints are used to consume and produce the requests, using endpoint bridging. The HTTP URI supplied by the client may be encoded in the usual way, to protect characters that have a particular meaning in a URI.

      We observe, however, that when an encoded URI is supplied by an HTTP client, the request that is routed to the receiver has its URI decoded, which causes a parsing failure.

      So, for example, if the client requests http://host1:port1/x=%3B then request received by the downstream HTTP server is http://host2:port2/x=; The presence of the un-encoded semicolon here breaks the URI parsing used by the client, because it was expecting to see "%3B" at this point.

      This behaviour is different from that observed with Jetty endpoints, which pass the URI without interpretation when bridging endpoints. However, the use of Jetty endpoints is not a workaround, because they lack certain features required by the application (partial URI matching, for example).

        1. camel-http4-2.15.0.redhat-620-SNAPSHOT.jar
          76 kB
        2. camel-uri.zip
          8 kB
        3. ENTESB-4737.zip
          334 kB
        4. Loopback__lo0.png
          Loopback__lo0.png
          535 kB
        5. reproducer.zip
          14 kB
        6. wireshark_output.png
          wireshark_output.png
          167 kB

            rhn-support-tasato Tadayoshi Sato
            rhn-support-kboone Kevin Boone
            Jan Bouska Jan Bouska
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: