Oops, minor correction. Apache actually returns 400 Bad Request
Here's the telnet session
GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1
server: msaegesserlpt
HTTP/1.1 400 Bad Request
Date: Thu, 13 Sep 2001 13:51:21 GMT
Server: Apache/1.3.19 (Win32) mod_jk
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
18b
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad
Req
uest</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request
that th
is server could not understand.<P>
client sent HTTP/1.1 request without
hostname
(see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbar<P>
<HR>
<ADDRESS>Apache
/1.3.19 Server at msaegesserlpt Port 8081</ADDRESS>
</BODY></HTML>
0
Connection to host lost.
Marc Saegesser
> -----Original Message-----
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 13, 2001 8:48 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: URI handling in tomcat 3.2.3
>
>
> I agree that this URI handling sucks. I'm the one that committed
> the change
> that made it happen and I still think it sucks. However, allowing these
> encoded characters opens some very large security problems.
>
> Also, even if TC 3.2.x allowed these characters, the resulting
> URL wouldn't
> be portable because several other web servers impose the same
> restrictions.
> In fact we lifted our restriction on encoded special characters straight
> from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then
> you would still get a 404 on Apache (at least on Apache 1.3.19
> which is what
> I tested with).
>
> If you need to pass this sort of data to a servlet (or CGI) the most
> portable way is to simply use a query string.
>
>
> Marc Saegesser
>
> > -----Original Message-----
> > From: Lars Oppermann [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 13, 2001 5:00 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: URI handling in tomcat 3.2.3
> >
> >
> > Hi everyone,
> >
> > we were in progress of moving our project to tomcat 3.2.3 when we came
> > accross the new handling of URIs (release-notes sec. 7.2).
> >
> > Since we are using the URI to transport other hierarchical information
> > then filesystem paths, we have the feeling, that this kind of
> > functionality belongs to the default servlet serving filesystem
> > requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI
> > lead to a 404 error seems to somewhat strange.
> > For Example:
> > http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource
> > would be rejected, before app has teh possibilty to look at the request
> > and ...hier://address/myfile... would be normalized to hier:/address.
> >
> > We are perfectly aware of the security concerns behind these changes.
> > However, they only apply when serving resources from the filesystem. A
> > URL's path-components however are in no way bound to the representaion
> > of filesystem paths.(After all, the U in URL stands for universal :)
> >
> > RFC 2396 states that '/' in an URI has another semantic meaning then %2F
> > in an URI. The '/' seperates path-components, while the %2F means a
> > slash character in a path-component. When such an URI is mapped to a
> > filesystem this would denote a filename that contains a slash. When the
> > system does not allow for such names, it is the responsebilty of the
> > filesystem servlet to report an error (404 since such a file must not
> > exist on unix for example).
> >
> > What are your opinions on this?
> >
> > Cheers
> > -Lars
> > --
> > ----------------------------------------------------------------------
> > Lars Oppermann <[EMAIL PROTECTED]> Sun Microsystems
> > Software Engineer - Sun ONE Webtop Sachsenfeld 4
> > Phone: +49 40 23646 959 D-20097 Hamburg
> > Fax: +49 40 23646 550 http://www.sun.com/webtop
