httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy Fielding <field...@beach.w3.org>
Subject Re: no2slash - apache 0.8.2
Date Tue, 25 Jul 1995 19:32:04 GMT
>Andrew wrote:
>>If PATH_INFO's *only* meant to contain recognisable UNIX path/file
>>structures then my example should have been bounced, not mauled but then
>>allowed to proceed. 
>
>But your example did conform to the UNIX path/file syntax, so there's no
>reason for it to be bounced.

There are lots of things that conform to the UNIX path/file syntax which
do bounce, so that is not an issue.  The fact is that we are dealing
with the URL namespace, and the URL namespace is mapped onto the filespace
(not the other way around).  If you don't want // in the path, then the
server should not allow it as a valid URL and return 404 (or 403).

>For an example of the pitfalls of using PATH_INFO for random data; consider
>trying to send the string "/../" as part of the PATH_INFO.
>
>e.g.
>  http://server.com/cgi-bin/test-cgi/REF='/../astr'
>
>Almost every server (and many browsers) will give you
>PATH_INFO = /adir'
>and I don't think this is particularly bad behaviour.

Actually, it is.  The ".." segment is only special when interpreting
relative URLs.  The NCSA server did this removal primarily because
browser authors have a particular mypopia regarding specs, and never
seem to get their implementations right.  What it should have done is
a 404, thus forcing the authors (and developers) to get it right before
the bloody thing worked at all.

>Even URL-encoding the .. doesn't help;
>http://server.com/cgi-bin/test-cgi/REF='/%2e%2e/astr'
>gives the same result. This may be a bug though. (Roy?)

Definitely a bug, even in the case of a relative URL.

......Roy

Mime
View raw message