[
https://issues.apache.org/jira/browse/HTTPCORE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717044#comment-17717044
]
Mark Thomas commented on HTTPCORE-744:
--------------------------------------
Yes, in this context (normalization) it is explicit.
The nature and purpose of syntax based normalization is such that the RFC has
to define the complete process. Adding or removing to the set of characters
that is affected by percent-encoding normalization changes the definition of
equivalent. The RFC is clear that only percent encoded octets that represent
unreserved characters should be decoded.
To put it another way, if it was permitted to switch the ';' and '=' in the
original URIs in question to their %nn forms without changing the meaning of
the URI then normalizing the two versions of the URI would result in the same
string. It doesn't. Therefore the two URIs are not equivalent. Therefore the
original transformation (replacing ';' and '=' with the %nn forms) was not
valid.
> HttpCore 5.2.1 does not correctly handle semi-colon (;) and equal sign (=)
> characters in URI set as Location header.
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-744
> URL: https://issues.apache.org/jira/browse/HTTPCORE-744
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.2.1
> Environment: httpclient5, version 5.1.2
> httpcore5, version 5.1.2
> javax.servlet-api, version 3.1.0
> Reporter: Krasimir Malchev
> Priority: Major
> Attachments: Simulation.zip
>
>
> If an http response has an URI in the Location header, which contains special
> symbols - semi-colon ( ; ) and equal sign (=), the URI parser of the
> underlaying URI builder encodes these symbols to %3B and %3D. Then the
> redirect will be performed using the encoded URI.
> {+}Real Use Case where the issue is detected with httpcomonents updated from
> version 4 to 5{+}: SAML Artifact binding in an IDP initiated SSO
> communication.
> A simple simulation program is attached to demonstrate the problem.
> +Test Case:+ There is a servlet and a client application.
> 1. The client application sends an HTTP GET request to the servlet with URI
> "http://localhost:8080/test/welcome";
> 2. The servlet receives the request and sends a redirect response with a
> relative location - /test/httpclient4/welcomeHttpClient
> 2.1. Before sending the response the redirect URL is encoded (by calling the
> method HttpServletResponse.encodeRedirectURL(String location)).
> 2.2.The latter method adds jsessionid at the end of the new location in
> accordance to the [Java Servlet Specification, section 7.1.3 - URL
> Rewriting|https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf].
> As a result, the redirect location becomes similar to
> _/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F_
> 3. When the response is received the httpclient parses the new location and
> encodes it to:
> http://localhost:8080/test/httpclient/welcomeHttpClient%3Bjsessionid%3DFD86C2C971F595C8459028D585BCF26F
> This is an issue, because the latter URL is redirected at the end with
> {_}{*}%3B{*}jsessionid{*}%3D{*}FD86C2C971F595C8459028D585BCF26{_}F (i.e. no
> such endpoint exists). Also _jsessionid_ is not recognized as a path
> parameter.
> The expected redirect URL is without encoded semi-colon and equal sign :
> http://localhost:8080/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F
> +Remarks:+
> * If the servlet redirects a full URI instead of a relative URI (for
> example,
> http://localhost:8080/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F,
> then the httpclient response is properly parsed and the redirect URL has no
> encoded semi-colon and equal sign characters.
> * If http client 4.5.5 and httpcore 4.4.9 are used, then the described issue
> is not present.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
