Within Tomcat Head / 3.3 there are a host of problems with https pages and
various url related methods (redirect, encodeURL, etc.) As Andreas
Stubenrauch notes in the above bug report, this is a very serious, show
stopper problem. What's more, he has found the source of the problem. In
org.apache.tomcat.facade.HttpServletResponseFacade.toAbsolute(String url)
There is a call to:
new URL(new URL(requrl), location)
Where requrl is a string representation of the current request, and location
is the page being encoded or redirected to. The inner URL() constructor is
going to try to obtain a URLStreamHandler for whatever scheme is associated
with the request url. However, with JDK 1.1 (and 1.2?), there is no https
URLStreamHandler included, so this throws a MalformedURLException, which
causes all the problems.
I've just done some looking around, and, unfortunately, an HTTPS
URLStreamHandler is a pretty complicated thing to come up with, and I'm not
seeing one which is available under a license by which we could include it.
We could require JSSE, but, that seems unacceptable to me, because of the
following (common) setup:
- User has SSL-enabled Apache (proprietary, open, whatever). It listens on
SSL 443, and forwards requests to TC.
- TC doesn't need to know anything about SSL, it only needs to be able to
generate https url's when it encodes or redirects.
To require users in that situation to obtain JSSE, with whatever
complexities encryption laws places on that process, seems ridiculous.
So, I'm thinking about writing a hack which handles https as a special case:
try {
url = new URL(new URL(requrl), location);
} catch (MalformedURLException e2) {
try {
if(requrl.startsWith("https://")) {
requrl = "http" + requrl.substring(5);
url = new URL(new URL(requrl), location);
return "https" + url.toString().substring(4);
}
}
catch(MalformedURLException e3) {}
return (location); // Give up
}
Other than the fact that this has the flavor of a disgusting hack, it seems
like a workable, pragmatic solution. But before I commit it, I wanted to
check with people who maybe have a deeper understanding of the way of the
URLStreamHandler and its friends. (I am trying the basic URL(requrl)
constructor first, so if the user does have an https URLStreamHandler
installed, it should find it). I think the above should respect
non-standard ports (another issue).
Can anyone tell me why the above is a bad idea? Or does it sound like a
reasonable way to go?
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
