[
https://issues.apache.org/jira/browse/HTTPCLIENT-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871236#comment-16871236
]
Hartmut Arlt commented on HTTPCLIENT-1995:
------------------------------------------
[~olegk] Could you please explain your last comment in more detail? The URI I
want to use for request submission is transformed in
URIUtils.rewrite(URI,HttpHost), not in java.net.URI.
Regarding scheme-specific normalization, RFC 7230 (HTTP 1.1 Message Syntax),
_Section 2.7.3: http and https URI Normalization and Comparison_ states: "Since
the "http" and "https" schemes conform to the URI generic syntax, such URIs are
normalized and compared according to the algorithm defined in Section 6 of
[RFC3986].... Characters other than those in the "reserved" set are equivalent
to their percent-encoded octets: the normal form is to not encode them (see
Sections 2.1 and 2.2 of [RFC3986])."
The ampersand character has no special meaning in path component - I am
absolutely with you in this point - but it is still a reserved character as per
RFC 3986.
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
