[
https://issues.apache.org/jira/browse/HTTPCLIENT-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152696#comment-17152696
]
Gary D. Gregory commented on HTTPCLIENT-1995:
---------------------------------------------
Pardon the sports analogy, but whenever I catch up on a ticket and discussion
surrounding this issue, I feel like I've walked in on a tennis tournament where
the players are brilliant, displaying great flourishes, but are confused by the
rulings made by the referees; it then becomes clear to the spectators that some
are playing by singles rules and others by doubles rules. I just run the
concession stand.
HttpClient 4 plays by these RFC rules
[https://hc.apache.org/httpcomponents-client-4.5.x/index.html]
* [RFC 1945|http://tools.ietf.org/html/rfc1945] - Hypertext Transfer Protocol
-- HTTP/1.0
* [RFC 2616|http://tools.ietf.org/html/rfc2616] - Hypertext Transfer Protocol
-- HTTP/1.1
* [RFC 2617|http://tools.ietf.org/html/rfc2617] - HTTP Authentication: Basic
and Digest Access Authentication
* [RFC 2396|http://tools.ietf.org/html/rfc2396] - Uniform Resource Identifiers
(URI): Generic Syntax
* [RFC 6265|http://tools.ietf.org/html/rfc6265] - HTTP State Management
Mechanism (Cookies)
HttpClient 5 plays by these RFC rules
[https://hc.apache.org/httpcomponents-client-5.0.x/index.html]
* [RFC 7230|http://tools.ietf.org/html/rfc7230] - Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing
* [RFC 7231|http://tools.ietf.org/html/rfc7231] - Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content
* [RFC 7235|http://tools.ietf.org/html/rfc7235] - Hypertext Transfer Protocol
(HTTP/1.1): Authentication
* [RFC 1945|http://tools.ietf.org/html/rfc1945] - Hypertext Transfer Protocol
-- HTTP/1.0
* [RFC 2817|http://tools.ietf.org/html/rfc2817] - Upgrading to TLS Within
HTTP/1.1
* [RFC 2818|http://tools.ietf.org/html/rfc2818] - HTTP Over TLS
* [RFC 6265|http://tools.ietf.org/html/rfc6265] - HTTP State Management
Mechanism (Cookies)
* [RFC 2396|http://tools.ietf.org/html/rfc2396] - Uniform Resource Identifiers
(URI): Generic Syntax
If we are going add support for a different RFC (like
[https://tools.ietf.org/html/rfc3986]) whether or not it obsoletes a currently
supported one, I'm pretty sure its only going to happen in the HC 5 line.
Since supporting a new-RFC is not a trivial amount of work, especially if you
want to allow for a backward compatibility toggle, we should at least
understand where this change would take place. My preference would be to let HC
4 settle into maintenance mode and focus on HC 5.
> Percent-encoded ampersand in URI path not preserved
> ---------------------------------------------------
>
> Key: HTTPCLIENT-1995
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1995
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.8, 4.5.9
> Environment: Linux Mint 19, OpenJDK 8
> Reporter: none_
> Priority: Major
>
> Starting with HttpClient 4.5.8, percent-encoded ampersand characters in URI
> path segments are not preserved any longer but written in decoded form to
> wire due to path normalization performed by URIUtils.rewriteURI(URI,
> HttpHost).
>
> According to RFC 3986 (page 11+), the ampersand character is a delimiter and
> thus needs to be percent-encoded when not used for this purpose. Path
> normalization, as performed by HttpClient v4.5.8+, creates a new URI that is
> not equivalent to the original URI and thus leads to misinterpretation on
> server/receiver side.
> ??URIs that differ in the replacement of a reserved character with its??
> ??corresponding percent-encoded octet are not equivalent. Percent-??
> ??encoding a reserved character, or decoding a percent-encoded octet??
> ??that corresponds to a reserved character, will change how the URI is??
> ??interpreted by most applications??.
>
> A very simple test case is as follows:
> {code:java}
> @Test
> public void testAmpersand() throws Throwable
> {
> final URI uri = new
> URI("http://example.org/some/path%26with%20percent/encoded/segments";);
> final URI uri2 = URIUtils.rewriteURI(uri, null);
>
> Assert.assertEquals(uri, uri2);
> }
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
