Antwort: [Mod_gzip] mod_gzip + mod_ssl + tomcat problem
mod_gzip@lists.over.net
mod_gzip@lists.over.net
Tue, 23 Mar 2004 16:35:05 +0100
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 0055A0BBC1256E60_=
Content-Type: text/plain; charset="US-ASCII"
Hi Viktor,
> While this generally works, there is the problem, that the tomcat server
> doesn't know, that he is proxyed over a secure socket. We use
> javax.servlet.http.HttpServletResponse.sendRedirect(encodeRedirectURL())
> in some places in our code and this sends a non-ssl URL back to the
client.
> See:
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/index.html
>
> While this could be solved programmatically (ie, s/^http:/https:/ before
> sending the redirect) it would be much cleaner if this problem could be
> solved by configuring tomcat and/or apache to handle this case properly.
>
> I searched google, but didn't anything that was relevant to my problem
> at hand. Any ideas?
Although I might well overlook something I 'm afraid the "translation" of
URLs
might already be the best you can do in Apache 1.3.
I could't even imagine one instance that "understands" your scenario which
actually wraps several layers around each other.
One might think that mod_proxy could translate the headers but then again
mod_proxy isn't aware that running SSL in your Virtual Host is a problem
for
the content you embed into this Virtual Host - your content could well
contain
nothing but relative links and thus be transparent for the protocol.
Then again, I'd rather not change your Java application as to generate
HTTPS
redirections because that would enforce running it under HTTPS which might
not always be what you want. I'd look for an appropriate place inside the
SSL virtual host to do this translation so that you can still use your
application
via HTTP (for testing purposes or whatnot) and have all SSL relevant
translations
located in the "outer layer".
Overall your scenario looks like the architecture of Apache 2.x might
support
this layer concept better than Apache 1.3 - so what about migrating to
Apache
2.0 and mod_deflate instead, and thus avoiding the "pair of Virtual Hosts"
trick?
(If you still want to use SSL then would your Jakarta software understand
what
kind of redirection URLs to generate once you run SSL and Jakarta in the
same
Virtual Host again?)
Regards, Michael
--=_alternative 0055A0BBC1256E60_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 color=red face="sans-serif"><b>Hi Viktor,</b></font>
<br>
<br>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>While
this generally works, there is the problem, that the tomcat server</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>doesn't
know, that he is proxyed over a secure socket. We use</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>javax.servlet.http.HttpServletResponse.sendRedirect(encodeRedirectURL())</tt></font>
<br><font size=2 color=red face="sans-serif"><b>></b></font><font size=2><tt>
in some</tt></font><font size=2 color=red face="sans-serif"><b> </b></font><font size=2><tt>places
in our code and this sends a non-ssl URL back to the client.</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>See:</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>http://jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/index.html</tt></font>
<br><font size=2 color=red face="sans-serif"><b>></b></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>While
this could be solved programmatically (ie, s/^http:/https:/ before</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>sending
the redirect) it would be much cleaner if this problem could be</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>solved
by configuring tomcat and/or apache to handle this case properly.</tt></font>
<br><font size=2 color=red face="sans-serif"><b>></b></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>I
searched google, but didn't anything that was relevant to my problem</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>at
hand.</tt></font><font size=2 color=red face="sans-serif"><b> </b></font><font size=2><tt>Any
ideas?<br>
<br>
</tt></font><font size=2 color=red face="sans-serif"><b>Although I might
well overlook something I 'm afraid the "translation" of URLs</b></font>
<br><font size=2 color=red face="sans-serif"><b>might already be the best
you can do in Apache 1.3.</b></font>
<br><font size=2 color=red face="sans-serif"><b>I could't even imagine
one instance that "understands" your scenario which</b></font>
<br><font size=2 color=red face="sans-serif"><b>actually wraps several
layers around each other.</b></font>
<br><font size=2 color=red face="sans-serif"><b>One might think that mod_proxy
could translate the headers but then again</b></font>
<br><font size=2 color=red face="sans-serif"><b>mod_proxy isn't aware that
running SSL in your Virtual Host is a problem for</b></font>
<br><font size=2 color=red face="sans-serif"><b>the content you embed into
this Virtual Host - your content could well contain</b></font>
<br><font size=2 color=red face="sans-serif"><b>nothing but relative links
and thus be transparent for the protocol.</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>Then again, I'd rather
not change your Java application as to generate HTTPS</b></font>
<br><font size=2 color=red face="sans-serif"><b>redirections because that
would enforce running it under HTTPS which might</b></font>
<br><font size=2 color=red face="sans-serif"><b>not always be what you
want. I'd look for an appropriate place inside the</b></font>
<br><font size=2 color=red face="sans-serif"><b>SSL virtual host to do
this translation so that you can still use your application</b></font>
<br><font size=2 color=red face="sans-serif"><b>via HTTP (for testing purposes
or whatnot) and have all SSL relevant translations</b></font>
<br><font size=2 color=red face="sans-serif"><b>located in the "outer
layer".</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>Overall your scenario looks
like the architecture of Apache 2.x might support</b></font>
<br><font size=2 color=red face="sans-serif"><b>this layer concept better
than Apache 1.3 - so what about migrating to Apache</b></font>
<br><font size=2 color=red face="sans-serif"><b>2.0 and mod_deflate instead,
and thus avoiding the "pair of Virtual Hosts" trick?</b></font>
<br><font size=2 color=red face="sans-serif"><b>(If you still want to use
SSL then would your Jakarta software understand what</b></font>
<br><font size=2 color=red face="sans-serif"><b>kind of redirection URLs
to generate once you run SSL and Jakarta in the same</b></font>
<br><font size=2 color=red face="sans-serif"><b>Virtual Host again?)</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>Regards, Michael</b></font>
--=_alternative 0055A0BBC1256E60_=--