You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tassilo Pilati <tp...@weboperations.com> on 2001/06/27 21:39:35 UTC

AW: URI Rewritng using Apache/mod_ssl..the old story

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