Re: /../ in an http URL

Simply put, the HTTP server is the only application capable of
determining whether ot not /../ is allowed in a Request-URI.

The rules in RFC 1808 only cover relative paths -- once the path
has been resolved into URL form, ".." and "." segments have no special
meaning to the parser.  NOTE that only the client does this parsing,
since the server receives the path in absolute form.  Some older
versions of Lynx are simply broken in this regard.

At the same time, any server worth its salt should prevent multiple
URLs from being mapped to the same resource by accident.  Thus, any
server that allows both

     GET /one/./two HTTP/1.0
and
     GET /one/two HTTP/1.0

to retrieve the same resource is being foolish.  The correct response is
either a redirect (301) or an error (403 or 404).

This does not mean that "/one/./two" is an invalid URL path -- that can
only be determined by the server (or server module/CGI script) which
defines the URL space for its resources.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 21 December 1995 00:33:49 UTC