|Summary:||RemoteIpFilter does not adjust getRequestURL()|
|Product:||Tomcat 8||Reporter:||Cristian Klein <cristiklein>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Details for how to reproduce the bug|
Description Cristian Klein 2015-11-11 18:12:00 UTC
Created attachment 33272 [details] Details for how to reproduce the bug When putting an HTTP server behind a forwarder -- such as nginx or Amazon CloudFront -- special HTTP headers are sent -- such as X-Forwarded-Proto and X-Forwarded-For -- to allow the server to reconstruct the URL that the client used for making the request. This is important, for example, to construct a meaningful "Location" HTTP response header. The purpose of the RemoteIpFilter is to give servlets the impression that they are operating on the original, pre-forwarded request. Hence, without changing any line of code, the existing servlets can construct meaningful URL for the client. Unfortunately, the wrapped request that RemoteIpFilter produces does not correctly implement getRequestURL(). In fact, it simply forwards this call to the wrapped request, which contains non-meaningful information about e.g., the HTTP schema . This currently breaks Jetty, which relies on getRequestURL to construct a correct "Location" header . (See attachment for details on how to reproduce the bug.) I'm not sure what the best technical solution would be. Should RemoteIpFilter.XForwardedRequest implement its own getRequestURL? I haven't found an implementation for it. Could somebody point me to it?  http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/8.0.24/org/apache/catalina/filters/RemoteIpFilter.java#444  http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-servlet-api/8.0.24/javax/servlet/http/HttpServletRequestWrapper.java#212  http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.jersey.containers/jersey-container-servlet-core/2.19/org/glassfish/jersey/servlet/ServletContainer.java#253
Comment 1 Mark Thomas 2015-11-12 14:54:10 UTC
Thanks for the report. This has been fixed in trunk, 8.0.x (for 8.0.29 onwards) and 7.0.x (for 7.0.66 onwards).