Bug 60482 - URL parameters parsed incorrectly using HTTP/2 connector
Summary: URL parameters parsed incorrectly using HTTP/2 connector
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.5.9
Hardware: PC All
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2016-12-15 07:28 UTC by Aaron Daniels
Modified: 2016-12-15 12:32 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Daniels 2016-12-15 07:28:37 UTC
I'm using Tomcat 8.5.9. It appears that query strings containing percent encoded ampersand (%26) and percent (%25) characters are not parsed correctly when using the HTTP/2 connector. Using HTTP 1.1, it works fine.

To reproduce:

1) create ROOT/test.jsp with these contents:

foo=[<%= request.getParameter("foo") %>]

2) Set up an HTTPS connector in server.xml that upgrades to HTTP/2 and start the server:
<Connector port="8443" scheme="https" secure="true" SSLEnabled="true" compression="on" address="">
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
        <SSLHostConfig protocols="TLSv1.1+TLSv1.2">
            <Certificate certificateKeyFile="conf\tls\key.pem"
                         certificateChainFile="conf\tls\STAR_credentialsmart_net.ca-bundle" />

3) Browse to https://localhost:8443/test.jsp?foo=b%26a

The result is:

4) Now comment out <UpgradeProtocol ...> in the HTTPS connector in server.xml and restart.

5) Browse to https://localhost:8443/test.jsp?foo=b%26a

The result is:

The access log also shows the URLs differently:
0:0:0:0:0:0:0:1 - - [15/Dec/2016:02:12:22 -0500] "GET /test.jsp?foo=b%26a HTTP/1.1" 200 14
0:0:0:0:0:0:0:1 - - [15/Dec/2016:02:12:36 -0500] "GET /test.jsp?foo=b&a HTTP/2.0" 200 12

And the logs show the message:
14-Dec-2016 23:48:59.846 FINE [catalina-exec-2] org.apache.tomcat.util.http.Parameters.processParameters Parameter starting at position [10] and ending at position [15] with a value of [10] was not followed by an = character
Comment 1 Remy Maucherat 2016-12-15 10:32:34 UTC
I don't really understand the reason of the URL decoding here: 

Most likely Parameters always has to do the decoding since we still live with these query string encoding configuration options.
Comment 2 Mark Thomas 2016-12-15 11:20:54 UTC
Other than me not thinking straight, I don't see a reason for that decoding either. Query string decoding has to be deferred to parameter parsing so that encoding of reserved characters - such as '&' - is handled correctly. Should be a simple fix.
Comment 3 Remy Maucherat 2016-12-15 12:32:58 UTC
Tests pass, and I added a test case. This will be in 9M16 and 8.5.10.