In case in matters, RFC 1630 states that:
PATH
The rest of the URI follows the colon in a format
depending on the scheme. The path is interpreted
in a manner dependent on the protocol being used.
However, when it contains slashes, these must
imply a hierarchical structure
I read this as meaning the slashes in "http://fubar"; are
required to be encoded. Page 9 of RFC 1630 contains
"Example 2", which illustrates this. Since Tomcat 3.3
and Tomcat 4.0 also disallow "%2F", we all have this issue.
Larry
> -----Original Message-----
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 24, 2001 9:24 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Tomcat 3.2.3 and getPathInfo
>
>
> Comments in line.
>
>
> Marc Saegesser
>
> > -----Original Message-----
> > From: Jason Hunter [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 23, 2001 11:32 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Tomcat 3.2.3 and getPathInfo
> >
> >
> > Marc Saegesser wrote:
> > >
> > > 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?
> >
> > Using SnoopServlet I see /http:/fubar just like you. My seeing the
> > http: being eaten was due to how the GoTo servlet responded to the
> > illegal URL being used. So that's good, it's only the
> double-slash to
> > single-slash issue. It's a hard issue, but a straightforward issue.
>
> I'm glad we're seeing the same thing. The issue can
> certainly be solved,
> after all, its only code. :-)
>
> > > 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.
> >
> > I don't recall any EG discussion about normalizing the URL
> before the
> > container sees it. Generally the spec makes contracts on the
> > "container" as it interfaces with the servlet and doesn't make any
> > statements about a web server might support a plug-in.
>
> This happened recently, Craig would probably have more details. The
> specification does discuss the mapping of URLs into servlets
> and this is
> where the problem lies. For example a URL like
>
> http://localhost:8080/examples/sercurity/../security/protected
> /index.jsp
>
> obviously refers to a resource inside an area protected by a
> <security-constraint> but it doesn't match the prefix <url-pattern> of
> /jsp/security/protected unless the URL is first normalized.
> The solution
> proposed was to normalize the URL as it entered the
> container. The value
> returned by getRequestURI() and any other method that returns
> the URI would
> *always* return the normalized URI. This solves the security
> constraint
> problems, but it seems it causes problems with path info.
>
> There two choices here. We either don't normalize the path info or we
> don't. I think you can make a case for both sides but I'd
> lean towards
> keeping it normalized.
>
> > > 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).
> >
> > Hmm... I wonder if Tomcat has the right to make illegal
> what HTTP would
> > allow?
>
> As I recall, our constraints were basically lifted from the
> Apache HTTP
> server. Our rationale was that it was far better to preclude
> some odd URLs
> than to leave open the possibility that files outside the web
> application
> could be accessed via the container. This was a *really* bad
> security hole.
>
> >
> > > 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.
> >
> > As I understand it, extra path info has to be returned in its simple
> > decoded form.
> >
> > -jh-
>
