Users questions should be posted on the users list. Please post all
follow ups to the users list. See http://tomcat.apache.org/lists.html
for what should be discussed on what list.
You might find a configurative solution at
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
especially
proxyName
If this Connector is being used in a proxy configuration, configure this
attribute to specify the server name to be returned for calls to
request.getServerName(). See Proxy Support for more information.
proxyPort
If this Connector is being used in a proxy configuration, configure this
attribute to specify the server port to be returned for calls to
request.getServerPort(). See Proxy Support for more information.
scheme
Set this attribute to the name of the protocol you wish to have returned
by calls to request.getScheme(). For example, you would set this
attribute to "https" for an SSL Connector. The default value is "http".
See SSL Support for more information.
Rainer Jung
Tino Schwarze wrote:
On Thu, Feb 16, 2006 at 03:24:52PM -0800, Casey Haakenson wrote:
We have a customer who is hitting our web GUI through a fairly
complicated SSH proxy scheme. For example, when they hit a page on our
site such as /redirect.jsp we do a
response.sendRedirect("/newpage.jsp"). This results in a 302 status
code and a Location header with the full URI
(http://somesite.com/newpage.jsp) which is the incorrect URL since the
proxy has been rewriting the URL's so far and this new one is the one
that the proxy is hitting not the original one the browser thinks it's
viewing.
Anyway, I have tested a change to CoyoteResponse.sendRedirect:1114 (we
are using 4.1.24) to send the "relative absolute" ("/newpage.jsp") path
back to the browser in the Location header. This appears to solve the
problem and work in all browsers I've been able to test, but am worried
that since you guys went to so much trouble making it include the
protocol, hostname, port, etc that this may break some odd browser or
case I'm not fully understanding at the moment.
AFAIK it's against HTTP specs. Redirects have to be absolute. For
example, lynx complains ("redirect URL is not absolute" or something
alike). IMO there's only one practical solution: Tell your application
which URLs will be used to access it and prepare the redirect URLs
according to the request (you can evaluate X-Forwarded-Host and similar
headers to get the original hostname).
Bye, Tino.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
