[ 
https://issues.apache.org/jira/browse/HTTPCORE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Krasimir Malchev updated HTTPCORE-744:
--------------------------------------
    Description: 
If an http response has an URI in the Location header, which contains special 
symbols - semi-column ( ; ) 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]).
Therefore 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 
%3Bjsessionid%3DFD86C2C971F595C8459028D585BCF26F (i.e. no such endpoint 
exists). Also jsessionid is not recognized as a path parameter.
The expected redirect URL is without encoded semi-column and equal sign : 
[http://localhost:8080/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F]

Remarks:
1) Note that 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 redrect URL has no encoded 
semi-column and equal sign character.

2) If http client 4.5.5 and httpcore 4.4.9 are used, then the described issue 
is not present! (client application is also attached)

  was:
If an http response has an URI in the Location header, which contains special 
symbols - semi-column (;) 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).
Therefore 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 
%3Bjsessionid%3DFD86C2C971F595C8459028D585BCF26F (i.e. no such endpoint 
exists). Also jsessionid is not recognized as a path parameter.
The expected redirect URL is without encoded semi-column and equal sign : 
http://localhost:8080/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F

Remarks:
1) Note that 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 redrect URL has no encoded 
semi-column and equal sign character.

2) If http client 4.5.5 and httpcore 4.4.9 are used, then the described issue 
is not present! (client application is also attached)


> HttpCore 5.2.1 does not correctly handle semi-column (;) 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-column ( ; ) 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]).
> Therefore 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 
> %3Bjsessionid%3DFD86C2C971F595C8459028D585BCF26F (i.e. no such endpoint 
> exists). Also jsessionid is not recognized as a path parameter.
> The expected redirect URL is without encoded semi-column and equal sign : 
> [http://localhost:8080/test/httpclient/welcomeHttpClient;jsessionid=FD86C2C971F595C8459028D585BCF26F]
> Remarks:
> 1) Note that 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 redrect URL has no encoded 
> semi-column and equal sign character.
> 2) If http client 4.5.5 and httpcore 4.4.9 are used, then the described issue 
> is not present! (client application is also attached)



--
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

Reply via email to