[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758258#comment-16758258
]
Clinton Gormley commented on HTTPCLIENT-1968:
---------------------------------------------
I think the issue is explained in this comment:
https://issues.apache.org/jira/browse/HTTPCLIENT-1960?focusedCommentId=16740468&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16740468
{quote}An extra %2F cannot be added manually because
{{setPath("/%2Fetc/motd")}} results in {{"/%252Fetc/motd"}} because the path
will be (correctly) URI-encoded.
{quote}
The comment after that provides the solution:
{quote}There should be a function added to set an "escaped" path instead of
only "unescaped" paths
{quote}
You should NEVER set unescaped paths as a single string - only as path
segments, which are then concat'ed with `/`. It is impossible to accurately
decode and encode paths that consist of more than one path segment where a path
segment includes a /.
For instance, imagine your path segments are `["foo", "bar/baz"]`. To convert
this to a path, you would encode each segment, then concat with `/`, to give
you `foo/bar%2Fbaz`. That string you could then use to set an encoded path
parameter. But joining with / before encoding would result in `foo/bar/baz`
which is completely different. There is no way you can encode that correctly.
So the only way to accept an unencoded path is as an array of segments.
> Encoded forward slashes are not preserved when rewriting URI
> ------------------------------------------------------------
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.5.7
> Reporter: Jay Modi
> Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when
> the HTTP client executes. I came across this when upgrading from 4.5.2 to
> 4.5.7 and my requests that contained an encoded forward slash suddenly
> started failing. The appears to be due to decoding and re-encoding of the
> path that takes place in the URIUtils#rewriteURI method. I've attached a
> patch that restores the old behavior but if a URI contains two slashes in a
> row in addition to an encoded slash the encoded forward slash will be decoded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
