[
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758142#comment-16758142
]
Julian Reschke commented on HTTPCLIENT-1968:
--------------------------------------------
{quote}It is irrelevant what RFC 3986 states. java.net.URI conforms to the RFC
2396.
{quote}
It is relevant, because RFC 3986 has obsoleted RFC 2396. Insisting on
compliance to an obsoleted spec is not helpful. That said, I don't think the
definitions in 2396 are materially different. (If they are, please point that
out).
{quote}There is no reference to RFC 3986 in RFC 2616.
{quote}
It has a reference to 2396, which has been obsoleted by RFC 3986. The same way
RFC 2616 has been obsoleted as well.
{quote}HttpClient needs to convert request URIs to abs_path representation when
the user supplies a request URI in the absolute form. While doing so HttpClient
need to deal with fringe cases like [https://host.com//p1/p2]. It is impossible
to handle such paths consistently without normalization.
{quote}
AFAICT, that string is not a valid URI (neither in 2396, nor 3986). It's
unfortunate that URI doesn't have a strict mode. So this is
garbage-in-garbage-out. Upon {{getPath()}}, the return value is "//p1/p2". That
is an invalid abs path according to the URI RFCs. So you could throw an
exception.
{quote}Those fringe cases arise form people's insistence on being able to embed
rubbish in the URI path component.
{quote}
Well. Optionally doing something with rubbish is one thing (I personally hate
it), but breaking *valid* URIs at the same time is another thing...
> 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: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
