You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Wolle <wo...@dorf.RWTH-Aachen.DE> on 2001/05/30 08:49:53 UTC
URI Rewritng using Apache/mod_ssl..the old story
I have just installed TC3.2.2 final, and URI Rewiting won't work over
mod_ssl
and apache.
without ssl it works fine, also.
I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
Or isn't it fixed on TC3.2.2 ??
When I install the two external classes from jdk jsse.jar and jnet.jar
in tomcat/lib and start it with an environment variable like bleow (old
bug #578 walkaround) it will work.
The only thing that's gone is that I don't have to patch the
HttpServletResponseFacade.java file out of
tomcat/lib/webserver.jar...
I've indeed tested this behavior with the standard class to test the
sessiontracking whoch comes with tomcat.
Greetings and thanks for inconvenience,
Michael
plz wrote back
Marc Saegesser wrote:
> A change very similar to what you propose for
HttpServletResponseFacade.java
> was already made for Tomcat 3.2.2b4. There are two conditions that I
know
> of where URL rewritting won't work. If you using AJP12 and an SSL
port
> other than 443 then Tomcat won't be told that the connection is secure
and
> will think that that the URL scheme is HTTP not HTTPS.
> HttpServletResponseFacade checks that the scheme of the URL to be
encoded
> and the scheme of the current request are the same. To encode an
HTTPS url
> you must be on an HTTPS request. [Note: I'm sure I really understand
this
> requirement, but its been this way for a long time.]
>
> So the two ways I know of for URL rewriting to fail are if you using
AJP12
> and SSL on something other than 443 or if your encoding an HTTPS URL
during
> an HTTP request. Are either of these true for your case?
>
> To help diagnose this, could you access the SnoopServlet that comes
with
> Tomcat via your SSL connection and post the results. This page will
> indicate whether Tomcat thinks the request is secure or not, and if it
> thinks the URL scheme is HTTPS.
>
> Thanks, we'll get this worked out.
>
> > -----Original Message-----
> > From: Wolle [mailto:wolle@dorf.RWTH-Aachen.DE]
> > Sent: Friday, May 04, 2001 5:19 AM
> > To: tomcat-user@jakarta.apache.org; GOMEZ Henri
> > Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
> >
> >
> >
> > Hello,
> > sorry I just wake up ;-)
> > Wolle wrote:
> >
> > > GOMEZ Henri wrote:
> > >
> > > > >That is a known Bug ,see
> > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
> > > > >Marc has said, that he has fixed in the current release
> > > > >TC3.2.2b4, but it
> > > > >won't work.
> > > > >What should I describe now ? The workaround was
> > > >
> > > > Fixed by costin in TC 3.3 since 01/04/22 11:56:03
> > >
> > > so I have all these things in TC3.2.2b4, fill it be insert in
> > TC3.2.2 final ?
> >
> > not fill -> new sentence
> > so I have to do all these things in TC3.2.2b4, will it be
> > completly insert in
> > TC3.2.2 final ?
> >
> > >
> > >
> > > >
> > > >
> > > > >1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir.
> > > > >2.set the TOMCAT_OPTS
> > > >
>=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> > > > >3. Modify the HttpServletResponseFacade.java:
> > > > >retrieving revision 1.6.2.3
> > > > >diff -u -r1.6.2.3 HttpServletResponseFacade.java
> > > > >---
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > >2001/03/06 17:38:13 1.6.2.3
> > > > >+++
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > >2001/03/20 13:29:41
> > > > >@@ -353,10 +353,14 @@
> > > > > return (false);
> > > > > if
(!request.getServerName().equalsIgnoreCase(url.getHost()))
> > > > > return (false);
> > > > >- // Set the URL port to HTTP default if not available
before
> > > > >comparing
> > > > >+ // Set the URL port to protocol default if not
> > > > >available before
> > > > >comparing
> > > > > int urlPort = url.getPort();
> > > > > if (urlPort == -1) {
> > > > >- urlPort = 80;
> > > > >+ if("http".equalsIgnoreCase(url.getProtocol())) {
> > > > >+ urlPort = 80;
> > > > >+ } else if
> > ("https".equalsIgnoreCase(url.getProtocol())) {
> > > > >+ urlPort = 443;
> > > > >+ }
> > > > > }
> > > > > if (request.getServerPort() != urlPort)
> > > > > return (false);
> > > >
> > > > That code need to be commited in 3.2.2b4
> > >
> > > only this, or the other two step also ?
> >
> > only this, or the other two steps also ?
> >
> >
> > >
> > >
> > > >
> > > >
> > > > >I have made this with TC3.2.2b2 and TC3.2.2b3, and this works.
> > > > >Then it doesn't matter if you use the ajp12 or ajp13 Protocol
> > > > >(I have read that this is important to use ajp13)
> > > >
> > > > You need ajp13 to get some SSL web-server vars.
> > > >
> > > > >so please help,
> > > >
> > > > You provide a patch which may be included in tomcat and must be
> > > > reviewed by Marc for approval but It seems ok to me and Costin
use
> > > > the same (cvs commit:
> > jakarta-tomcat/src/facade22/org/apache/tomcat/facade
> > > > HttpServletResponseFacade.java)
> > >
> > > thnaks and this will be the last questions about that problem ;-),
> > > Greetings Wolle
> >
> > thanks and this will be the last questions about that problem ;-),
> > Greetings Wolle
> >
> > ;-)
> > thanks for inconvenience
> > Michael
Re: URI Rewritng using Apache/mod_ssl..the old story
Posted by Rainer Jung <ra...@kippdata.de>.
As far as I understand the fix does not mean, that you get rid of jsse.jar
and jnet.jar.
Core Java does not include an https protocol handler, but such a thing is
implicitely used in http-URL-creation inside tomcat (although that could be
done easier). Java is open to add new protocol handlers. The way it works
is exactly by using own or third party protocol handlers and by defining
java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
(or to something else which knows about your own or third party protocol
handlers).
At that point your java application will be https enabled. The problem does
not occur with http, since standard java contains an http protocol handler
and the standard java.protocol.handler.pkgs knows about that one.
Of course as long as you don't really want tomcat itself to talk https
(e.g. the browser talks https to apache and you enable "JkExtractSSL On"
for mod_jk, so that redirects and forwards go to a correct https-URL) you
could think of supplying tomcat with basic https-URL-understanding not
using the fully featured protocol handlers. On the other side, since one
would like to have the ability to use https directly from tomcat you would
have to prepare to use the protocol handlers any way.
Rainer Jung
At 08:49 30.05.01 , you wrote:
>I have just installed TC3.2.2 final, and URI Rewiting won't work over
>mod_ssl
>and apache.
>without ssl it works fine, also.
>I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
>Or isn't it fixed on TC3.2.2 ??
>When I install the two external classes from jdk jsse.jar and jnet.jar
>in tomcat/lib and start it with an environment variable like bleow (old
>bug #578 walkaround) it will work.
>The only thing that's gone is that I don't have to patch the
>HttpServletResponseFacade.java file out of
>tomcat/lib/webserver.jar...
>I've indeed tested this behavior with the standard class to test the
>sessiontracking whoch comes with tomcat.
>
>Greetings and thanks for inconvenience,
>Michael
>plz wrote back
>
>Marc Saegesser wrote:
>
> > A change very similar to what you propose for
>HttpServletResponseFacade.java
> > was already made for Tomcat 3.2.2b4. There are two conditions that I
>know
> > of where URL rewritting won't work. If you using AJP12 and an SSL
>port
> > other than 443 then Tomcat won't be told that the connection is secure
>and
> > will think that that the URL scheme is HTTP not HTTPS.
> > HttpServletResponseFacade checks that the scheme of the URL to be
>encoded
> > and the scheme of the current request are the same. To encode an
>HTTPS url
> > you must be on an HTTPS request. [Note: I'm sure I really understand
>this
> > requirement, but its been this way for a long time.]
> >
> > So the two ways I know of for URL rewriting to fail are if you using
>AJP12
> > and SSL on something other than 443 or if your encoding an HTTPS URL
>during
> > an HTTP request. Are either of these true for your case?
> >
> > To help diagnose this, could you access the SnoopServlet that comes
>with
> > Tomcat via your SSL connection and post the results. This page will
> > indicate whether Tomcat thinks the request is secure or not, and if it
>
> > thinks the URL scheme is HTTPS.
> >
> > Thanks, we'll get this worked out.
> >
> > > -----Original Message-----
> > > From: Wolle [mailto:wolle@dorf.RWTH-Aachen.DE]
> > > Sent: Friday, May 04, 2001 5:19 AM
> > > To: tomcat-user@jakarta.apache.org; GOMEZ Henri
> > > Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
> > >
> > >
> > >
> > > Hello,
> > > sorry I just wake up ;-)
> > > Wolle wrote:
> > >
> > > > GOMEZ Henri wrote:
> > > >
> > > > > >That is a known Bug ,see
> > > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
> > > > > >Marc has said, that he has fixed in the current release
> > > > > >TC3.2.2b4, but it
> > > > > >won't work.
> > > > > >What should I describe now ? The workaround was
> > > > >
> > > > > Fixed by costin in TC 3.3 since 01/04/22 11:56:03
> > > >
> > > > so I have all these things in TC3.2.2b4, fill it be insert in
> > > TC3.2.2 final ?
> > >
> > > not fill -> new sentence
> > > so I have to do all these things in TC3.2.2b4, will it be
> > > completly insert in
> > > TC3.2.2 final ?
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir.
> > > > > >2.set the TOMCAT_OPTS
> > > > >
> >=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> > > > > >3. Modify the HttpServletResponseFacade.java:
> > > > > >retrieving revision 1.6.2.3
> > > > > >diff -u -r1.6.2.3 HttpServletResponseFacade.java
> > > > > >---
>src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > > >2001/03/06 17:38:13 1.6.2.3
> > > > > >+++
>src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > > >2001/03/20 13:29:41
> > > > > >@@ -353,10 +353,14 @@
> > > > > > return (false);
> > > > > > if
>(!request.getServerName().equalsIgnoreCase(url.getHost()))
> > > > > > return (false);
> > > > > >- // Set the URL port to HTTP default if not available
>before
> > > > > >comparing
> > > > > >+ // Set the URL port to protocol default if not
> > > > > >available before
> > > > > >comparing
> > > > > > int urlPort = url.getPort();
> > > > > > if (urlPort == -1) {
> > > > > >- urlPort = 80;
> > > > > >+ if("http".equalsIgnoreCase(url.getProtocol())) {
> > > > > >+ urlPort = 80;
> > > > > >+ } else if
> > > ("https".equalsIgnoreCase(url.getProtocol())) {
> > > > > >+ urlPort = 443;
> > > > > >+ }
> > > > > > }
> > > > > > if (request.getServerPort() != urlPort)
> > > > > > return (false);
> > > > >
> > > > > That code need to be commited in 3.2.2b4
> > > >
> > > > only this, or the other two step also ?
> > >
> > > only this, or the other two steps also ?
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >I have made this with TC3.2.2b2 and TC3.2.2b3, and this works.
> > > > > >Then it doesn't matter if you use the ajp12 or ajp13 Protocol
> > > > > >(I have read that this is important to use ajp13)
> > > > >
> > > > > You need ajp13 to get some SSL web-server vars.
> > > > >
> > > > > >so please help,
> > > > >
> > > > > You provide a patch which may be included in tomcat and must be
> > > > > reviewed by Marc for approval but It seems ok to me and Costin
>use
> > > > > the same (cvs commit:
> > > jakarta-tomcat/src/facade22/org/apache/tomcat/facade
> > > > > HttpServletResponseFacade.java)
> > > >
> > > > thnaks and this will be the last questions about that problem ;-),
>
> > > > Greetings Wolle
> > >
> > > thanks and this will be the last questions about that problem ;-),
> > > Greetings Wolle
> > >
> > > ;-)
> > > thanks for inconvenience
> > > Michael
>
AW: URI Rewritng using Apache/mod_ssl..the old story
Posted by Tassilo Pilati <tp...@weboperations.com>.
Hi guys,
i have been following this subject around for a while. In the 3.2.2 final
version of Tomcat URL rewritting also does not work in standalone mode (port
80). This seems really, really strange ... I wonder what these programmers
are doing. Have you heard about a solution ?
Tassilo
-----Ursprungliche Nachricht-----
Von: Wolle [mailto:wolle@dorf.RWTH-Aachen.DE]
Gesendet: Mittwoch, 30. Mai 2001 08:50
An: tomcatDev; tomcatUser
Betreff: URI Rewritng using Apache/mod_ssl..the old story
I have just installed TC3.2.2 final, and URI Rewiting won't work over
mod_ssl
and apache.
without ssl it works fine, also.
I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
Or isn't it fixed on TC3.2.2 ??
When I install the two external classes from jdk jsse.jar and jnet.jar
in tomcat/lib and start it with an environment variable like bleow (old
bug #578 walkaround) it will work.
The only thing that's gone is that I don't have to patch the
HttpServletResponseFacade.java file out of
tomcat/lib/webserver.jar...
I've indeed tested this behavior with the standard class to test the
sessiontracking whoch comes with tomcat.
Greetings and thanks for inconvenience,
Michael
plz wrote back
Marc Saegesser wrote:
> A change very similar to what you propose for
HttpServletResponseFacade.java
> was already made for Tomcat 3.2.2b4. There are two conditions that I
know
> of where URL rewritting won't work. If you using AJP12 and an SSL
port
> other than 443 then Tomcat won't be told that the connection is secure
and
> will think that that the URL scheme is HTTP not HTTPS.
> HttpServletResponseFacade checks that the scheme of the URL to be
encoded
> and the scheme of the current request are the same. To encode an
HTTPS url
> you must be on an HTTPS request. [Note: I'm sure I really understand
this
> requirement, but its been this way for a long time.]
>
> So the two ways I know of for URL rewriting to fail are if you using
AJP12
> and SSL on something other than 443 or if your encoding an HTTPS URL
during
> an HTTP request. Are either of these true for your case?
>
> To help diagnose this, could you access the SnoopServlet that comes
with
> Tomcat via your SSL connection and post the results. This page will
> indicate whether Tomcat thinks the request is secure or not, and if it
> thinks the URL scheme is HTTPS.
>
> Thanks, we'll get this worked out.
>
> > -----Original Message-----
> > From: Wolle [mailto:wolle@dorf.RWTH-Aachen.DE]
> > Sent: Friday, May 04, 2001 5:19 AM
> > To: tomcat-user@jakarta.apache.org; GOMEZ Henri
> > Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
> >
> >
> >
> > Hello,
> > sorry I just wake up ;-)
> > Wolle wrote:
> >
> > > GOMEZ Henri wrote:
> > >
> > > > >That is a known Bug ,see
> > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
> > > > >Marc has said, that he has fixed in the current release
> > > > >TC3.2.2b4, but it
> > > > >won't work.
> > > > >What should I describe now ? The workaround was
> > > >
> > > > Fixed by costin in TC 3.3 since 01/04/22 11:56:03
> > >
> > > so I have all these things in TC3.2.2b4, fill it be insert in
> > TC3.2.2 final ?
> >
> > not fill -> new sentence
> > so I have to do all these things in TC3.2.2b4, will it be
> > completly insert in
> > TC3.2.2 final ?
> >
> > >
> > >
> > > >
> > > >
> > > > >1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir.
> > > > >2.set the TOMCAT_OPTS
> > > >
>=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> > > > >3. Modify the HttpServletResponseFacade.java:
> > > > >retrieving revision 1.6.2.3
> > > > >diff -u -r1.6.2.3 HttpServletResponseFacade.java
> > > > >---
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > >2001/03/06 17:38:13 1.6.2.3
> > > > >+++
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
> > > > >2001/03/20 13:29:41
> > > > >@@ -353,10 +353,14 @@
> > > > > return (false);
> > > > > if
(!request.getServerName().equalsIgnoreCase(url.getHost()))
> > > > > return (false);
> > > > >- // Set the URL port to HTTP default if not available
before
> > > > >comparing
> > > > >+ // Set the URL port to protocol default if not
> > > > >available before
> > > > >comparing
> > > > > int urlPort = url.getPort();
> > > > > if (urlPort == -1) {
> > > > >- urlPort = 80;
> > > > >+ if("http".equalsIgnoreCase(url.getProtocol())) {
> > > > >+ urlPort = 80;
> > > > >+ } else if
> > ("https".equalsIgnoreCase(url.getProtocol())) {
> > > > >+ urlPort = 443;
> > > > >+ }
> > > > > }
> > > > > if (request.getServerPort() != urlPort)
> > > > > return (false);
> > > >
> > > > That code need to be commited in 3.2.2b4
> > >
> > > only this, or the other two step also ?
> >
> > only this, or the other two steps also ?
> >
> >
> > >
> > >
> > > >
> > > >
> > > > >I have made this with TC3.2.2b2 and TC3.2.2b3, and this works.
> > > > >Then it doesn't matter if you use the ajp12 or ajp13 Protocol
> > > > >(I have read that this is important to use ajp13)
> > > >
> > > > You need ajp13 to get some SSL web-server vars.
> > > >
> > > > >so please help,
> > > >
> > > > You provide a patch which may be included in tomcat and must be
> > > > reviewed by Marc for approval but It seems ok to me and Costin
use
> > > > the same (cvs commit:
> > jakarta-tomcat/src/facade22/org/apache/tomcat/facade
> > > > HttpServletResponseFacade.java)
> > >
> > > thnaks and this will be the last questions about that problem ;-),
> > > Greetings Wolle
> >
> > thanks and this will be the last questions about that problem ;-),
> > Greetings Wolle
> >
> > ;-)
> > thanks for inconvenience
> > Michael