-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
guice servlet: HttpServletRequest.getPathInfo not decoded #745
Comments
From t.cservenak on February 13, 2014 12:53:27 Looks like a problem at this place, as it wraps original Request but calculates the pathInfo (should be decoded) using requestUrl (is not decoded): https://code.google.com/p/google-guice/source/browse/extensions/servlet/src/com/google/inject/servlet/ServletDefinition.java?r=389cb718a70cd11fdf9c336209246ebcfe944755#205 |
From t.cservenak on February 14, 2014 03:40:34 Proposed patch sonatype/sisu-guice#8 |
From ukjung.kim on February 19, 2014 20:01:47 I have same issue with it. Please refer following discussion. https://groups.google.com/forum/#!topic/repo-discuss/px6X8_HOMPQ |
BTW in the |
@oberlies , would you be able to supply a pull request with the fix+test? Thanks! |
@sameb FYI there's a working patch+tests here: https://github.com/sonatype/sisu-guice/blob/master/PATCHES/GUICE_745_getpathinfo_not_decoded.patch which we've used successfully in production (this fix was originally suggested by Tamas a few comments above in #745 (comment)) |
Sorry, no time for this now, but I can share the code & test how to get from the current
Test:
|
@cstamas -- could you sign the Google Contributor CLA @ https://developers.google.com/open-source/cla/individual (see the 'Sign Electronically' at the bottom) so I can incorporate your patch from #745 (comment) (also contributed to sisu @ sonatype/sisu-guice#8)? If you'd like to open a new pull request to Guice w/ the patch after signing the CLA, I can merge it directly from the PR, or I can manually patch your patch... but both need your CLA. Thanks! |
CLA signed, PR created: |
PR merged. |
The fix for Guice issue #745[1] causes getPathInfo() within the GuiceFilter to return decoded values, eliminating the difference between "foo/bar" and "foo%2Fbar". This is in spec with the servlet standard, whose javadoc for getPathInfo[2] states that the return value be "decoded by the web container". Work around this by extracting the path part directly from the request URI, which is unmodified by the container. This is copying the Guice behavior prior to the bugfix. We do this with a static method rather than using our own HttpServletRequestWrapper as we don't want to produce a request wrapper that is not in spec. [1] google/guice#745 [2] http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getPathInfo() Change-Id: I48fb32710d45f573fb167c6344ad76541672858c
Due to the Guice issue [1] cloning of a repository with a space in its name was impossible. If the space wasn't encoded: $ git clone 'http://gerrit/My Project' then such a request failed already in Jetty code. If the space was encoded: $ git clone 'http://gerrit/My+Project' or: $ git clone 'http://gerrit/My%20Project' then the HttpServletRequest.getPathInfo in the GitOverHttpServlet would return a non-decoded string i.e. "My%20Project' and the project wouldn't be found. The HttpServletRequest.getPathInfo is expected to return a decoded string [2]. Unfortunately, there is no Guice release which contains the bugfix for the issue [1]. Workaround: decode the projectName in the GitOverHttpServlet.Resolver explicitly. [1] google/guice#745 [2] http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getPathInfo() Change-Id: I8872cd2d1bab3f8e454d0d7399b35eb850068042
This reverts commit 304130b. This was added as a workaround for Guice issue #745 [1]. Since then, a fix [2] has been merged and is included in Guice version 4.0, which we are now using. [1] google/guice#745 [2] cstamas/guice@41c126f Change-Id: I8048a9e8897d8b4e42a0f518d2deed5e17264bcf
The XDocServlet needs the endcoded URL path, but it used HttpServletRequest.getPathInfo() to retrieve it which returns the decoded path. So far this worked because there was a bug in Guice [1] that made HttpServletRequest.getPathInfo() return the encoded path. Now this bug was fixed in Guice and Gerrit was updated to use the new Guice version. Hence the XDocServlet started to fail and needs to be adapted. [1] google/guice#745 Change-Id: Ia14908ed0970e9e5eda0569e345c14fb5f255709 Signed-off-by: Edwin Kempin <ekempin@google.com> (cherry picked from commit 10c5263)
The XDocServlet needs the endcoded URL path, but it used HttpServletRequest.getPathInfo() to retrieve it which returns the decoded path. So far this worked because there was a bug in Guice [1] that made HttpServletRequest.getPathInfo() return the encoded path. Now this bug was fixed in Guice and Gerrit was updated to use the new Guice version. Hence the XDocServlet started to fail and needs to be adapted. [1] google/guice#745 Change-Id: Ia14908ed0970e9e5eda0569e345c14fb5f255709 Signed-off-by: Edwin Kempin <ekempin@google.com>
The ImageServlet needs the encoded URL path, but it used HttpServletRequest.getPathInfo() to retrieve it which returns the decoded path. So far this worked because there was a bug in Guice [1] that made HttpServletRequest.getPathInfo() return the encoded path. Now this bug was fixed in Guice and Gerrit was updated to use the new Guice version. Hence the ImageServlet started to fail and needs to be adapted. [1] google/guice#745 Change-Id: Ie44786acaa70b9612572727dad856d3fdcf472ae Signed-off-by: Edwin Kempin <ekempin@google.com>
From matt@hillsdon.net on April 11, 2013 06:52:21
getPathInfo in the anonymous HttpServletRequestWrapper in ServletDefinition.doService does not perform URL decoding, but it is required to do so by the servlet spec.
The inputs, getRequestURI and getContextPath, are provided by the container and are (correctly) provided without decoding.
The HttpServletRequest docs for getPathInfo say "a String, decoded by the web container". Tomcat decodes it, and provides container-level configuration to control the character encoding used. See http://wiki.apache.org/tomcat/FAQ/CharacterEncoding "How do I change how GET parameters are interpreted?"
I switched an existing application to use Guice to create my servlets and tests for character encoding failed as the raw string was returned from getPathInfo.
Original issue: http://code.google.com/p/google-guice/issues/detail?id=745
The text was updated successfully, but these errors were encountered: