[
https://issues.apache.org/jira/browse/HTTPCORE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717061#comment-17717061
]
Oleg Kalnichevski commented on HTTPCORE-744:
--------------------------------------------
[~markt] What URIBuilder does is conceptually very simple: it decomposes the
original URI into its constituent components based on the component
specification of the RFC and then re-assembles the URI based on the same
component specification. Now you are appear to be saying that URI normalization
is something else. This makes no sense to me what so ever, but so be it.
[~michael-o] I propose we do the following: rename `#normalizeSyntax` to
`#rebuild` or some such and deprecate the actual `#normalizeSyntax`. Whoever is
so inclined is welcome to undeprecate the method and re-implement it based on
the latest popular interpretation of the RFC there is.
Oleg
> 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
