I just tried this using the SnoopServlet that ships with Tomcat using a URL
like
http://localhost:8080/servlet/SnoopServlet/http://fubar
and got
/http:/fubar
as the path info. Your description makes it look like your losing http: in
addition to the one of the /s. Is this what your seeing?
This problem is almost certainly caused the URL normalization code that got
put into 3.2.3 to fix a serious security hole. This is going to be
difficult to resolve. We have to normalize the URL before the servlet
container uses it (I think this is even going to be added to the latest
servlet specification) or some really bad things can happen with prefix
mapping. However, until we've done the prefix mapping we can't know what
part of the URL refers to a servlet and what part is path info. Getting
back the original non-normalized path info is going to be tricky.
This is even worse because we also won't allow the URL to be encoded like
http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar
because we make some rather draconian precautions to ensure that nastily
encoded URLs can't obtain access to protected resources (or even resources
outside the webapp).
I'll have to give this one some thought. If URL normalization is being
added to the specification then there should also some guidance on how it
relates to path info. I'll CC this to servletapi-feedback.
Marc Saegesser
> -----Original Message-----
> From: Jason Hunter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 23, 2001 5:00 PM
> To: [EMAIL PROTECTED]
> Subject: Tomcat 3.2.3 and getPathInfo
>
>
> It seems that Tomcat 3.2.3 has a bug (a regression) that hits my book's
> Example 5-5. See:
>
> http://www.servlets.com/jservlet2/examples/ch05/index.html#ex05_05
>
> The bug is that for the following URL:
>
> http://www.servlets.com/jservlet2/examples/ch05/goto/http://www.se
> rvlets.com
>
> the goto servlet should have extra path info of
> "http://www.servlets.com"; and in fact does with Tomcat 3.2.1 but with
> 3.2.3 it now returns "/www.servlets.com". My guess is the server may be
> trying to do a windows to unix filename conversion? It could also be a
> side effect of decoding, although there are no special chars there to be
> decoded.
>
> Is this a known issue? I didn't find anything with a quick list scan.
>
> -jh-
