A redirect can't be done relatively... The HTTP/1.1 spec for the Location: header states:
"The field value consists of a single absolute URI." http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 So the server must figure out how to construct an absolute URL. I've been bitten by the same thing but in another context where I terminate SSL on my front servers and then forward the traffic onto port 80 on my back servers, however I do set the apache environment variable HTTPS=on which means that my java API gets fooled into thinking the URL was secure, e.g. request.isSecure() returns true request.getScheme() returns https, however request.getPort() returns 80, so when I do a redirect it constructs the URL as "https://someserver:80/something" which fails... I would like to see a good solution to these redirection/port/hos issues once and for all. I believe it should be completely configurable on the connectors what host and port should be used for redirection for https and http. There are several bits to solve, and there must be separate configurations for http and https. 1) hostname changes, e.g. request comes in to host A and is forwarded by mod_proxy or similar to host B. 2) port changes, e.g. request comes in to host A on port 80 and is forwarded by mod_proxy or so to host B port 1234. 3) "context" changes, e.g. request comes into http://A:80/some/path/this and is rewritten to http://B:1234/path/this ... I use this to have a "shared" SSL certificate e.g. https://shared.host/site/www.somesite.com/webapp/path is rewritten to http://www.somesite.com/webapp/path in a generic way. This goes completely pear shaped since session cookie path is set to "/webapp" and that results in the browser being completely confused. (It doesn't send the cookie back since the requested URL is not https://shared.host/webapp". I haven't thought through what needs to be done to solve any of this. But one day I'm sure I get time to do it :) Martin > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: 17 December 2002 01:11 > To: Tomcat Developers List > Subject: mod_jk and load balancer - bug? > > > here is a scenario > > hardware stack > > LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat > 4.1.12(port8080/8009) > > 1. The load balancer receives a request for > http://server/somecontext/ 2. The load > balancer forwards this > to apache. Apache detects /somecontext/ and makes a request > to Tomcat 3. Tomcat gets the request GET /somecontext/ and > looks up welcome files 4. Tomcat finds index.jsp as a welcome > file 5. Tomcat constructs a redirect using the absolute URL > it got from Apache > > and here is the problem, in step 5 tomcat constructs an > absolute URL, and uses the port number from Apache which was > 81. hence the redirect will go to port 81. > > the response back to the server is > Location:http://server:81/somecontext/index.jsp --which is > wrong, the request came in on port 80 > > when it would have been better if the response was the relative URL. > > Is this a bug, or could we add a feature to be able to > configure the Coyote connector to generate absolute or > relative urls on sendRedirect > > Filip > > ~ > Namaste - I bow to the divine in you > ~ > Filip Hanik > Software Architect > www.filip.net > > > -- > To unsubscribe, e-mail: > <mailto:tomcat-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>