[
https://issues.apache.org/jira/browse/HTTPCORE-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934301#comment-17934301
]
Arturo Bernal commented on HTTPCORE-778:
----------------------------------------
For what I understand, RFC 3986 doesn’t issue a direct command like “do not
encode the fragment.” Instead, it merely defines which characters are allowed
unencoded. Section 3.5 defines the fragment as:
{code:java}
fragment = *( pchar / "/" / "?"{code}
and
{code:java}
pchar = unreserved / pct-encoded / sub-delims / ":" / "@". {code}
Frankly, the RFC is bluntly vague here—it leaves the decision entirely up to
each implementer’s interpretation.
> URIBuilder uses incorrect encoding method for URI fragment
> ----------------------------------------------------------
>
> Key: HTTPCORE-778
> URL: https://issues.apache.org/jira/browse/HTTPCORE-778
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.3.3
> Reporter: Peter Halicky
> Priority: Major
>
> URI fragment is encoded in URIBuilder using:
> {code:java}
> PercentCodec.encode(sb, this.fragment, this.charset); {code}
> (line 401, end of buildString method)
> This encodes all characters except UNRESERVED using the percent-format.
> As per (obsoleted) RFC2396, URI fragment should use URIC safe-chars.
> As per RFC3986, quite a bit more characters should not be encoded:
> {code:java}
> pct-encoded = "%" HEXDIG HEXDIG
> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
> sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" /
> "="
> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
> fragment = *( pchar / "/" / "?" ) {code}
> Note that URIBuilder in httpclient 4.5.13 conforms to at least the old
> RFC2396, as it uses URIC set of safe characters (i.e. this is in fact a
> regression).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]