Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Mon, 14 Dec 2015 14:41:46 +0000 (UTC)
From: "Edward Welch (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12909492.1446391311000.14610.1450104106617@Atlassian.JIRA>
In-Reply-To: <JIRA.12909492.1446391311000@Atlassian.JIRA>
References: <JIRA.12909492.1446391311000@Atlassian.JIRA>
 <JIRA.12909492.1446391311973@arcas>
Subject: [jira] [Updated] (CAMEL-9281) Http4 component removes trailing
 slashes from http requests (producer)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CAMEL-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edward Welch updated CAMEL-9281:
--------------------------------
    Affects Version/s: 2.16.1

> Http4 component removes trailing slashes from http requests (producer)
> ----------------------------------------------------------------------
>
>                 Key: CAMEL-9281
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9281
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-http, camel-http4
>    Affects Versions: 2.15.4, 2.16.1
>            Reporter: Edward Welch
>
> I have created a scenario which seems to exploit a bug in the HttpHelper createURL method.
> My use case:
> Using http4 component in an http proxy with bridgeEndpoint true
> Send a request such as http://somesite/contextpath
> Request is forwarded by my proxy to a tomcat server.  Tomcat will reply with a 302 and a new Location of http://somesite/contextpath/ as this is a built in behavior of tomcat to redirect the caller to the contextpath INCLUDING the trailing slash
> I have http client configured with httpClient.redirectsEnabled=false
> Therefore the 302 is sent back through my proxy to the caller.
> The caller then makes the call to http://somesite/contextpath/
> This is where the problem occurs,  within the createUrl method:
> {code}
>         String path = exchange.getIn().getHeader(Exchange.HTTP_PATH, String.class);
>         // NOW the HTTP_PATH is just related path, we don't need to trim it
>         if (path != null) {
>             if (path.startsWith("/")) {
>                 path = path.substring(1);
>             }
>             if (path.length() > 0) {
>                 // make sure that there is exactly one "/" between HTTP_URI and
>                 // HTTP_PATH
>                 if (!uri.endsWith("/")) {
>                     uri = uri + "/";
>                 }
>                 uri = uri.concat(path);
>             }
>         }
> {code}
> When the second request is made with the trailing slash, the string "path" is / (just a single forward slash)
> This hits the first conditional and results in true, which the following substring then removes this slash.
> Now path.length() is not > 0 so the second conditional evaluates false.
> And we end up with a uri returned that no longer has the trailing slash.
> This is sent to Tomcat, Tomcat then promptly returns another 302 and a redirect loop is created.
> I think the intent of this block of code is to combine the uri and path and make sure there isn't a duplicate forward slash?
> So the simplest fix I can suggest would be something like
> {code}
>         String path = exchange.getIn().getHeader(Exchange.HTTP_PATH, String.class);
>         // NOW the HTTP_PATH is just related path, we don't need to trim it
>         if (path != null && ! path.equals("/")) {
>             if (path.startsWith("/")) {
>                 path = path.substring(1);
>             }
>             if (path.length() > 0) {
>                 // make sure that there is exactly one "/" between HTTP_URI and
>                 // HTTP_PATH
>                 if (!uri.endsWith("/")) {
>                     uri = uri + "/";
>                 }
>                 uri = uri.concat(path);
>             }
>         }
> {code}
> Where we would just check for this case explicitly with:
> if (path != null && ! path.equals("/")) {
> Thoughts?
> I could probably put together a PR and add some test cases


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)