>Number: 284 >Category: general >Synopsis: GET request with trailing ".." needs a REDIRECT >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache (Apache HTTP Project) >State: open >Class: change-request >Submitter-Id: apache >Arrival-Date: Sat Mar 29 02:40:01 1997 >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2b2 >Environment: Linux (but problem is not OS-dependent) >Description: Normally, Apache sends a 302 for a directory path that does not have a trailing slash, but it fails to do so for a path ending in "..".
This came to light because a spider/robot program named Teleport Pro incorrectly sends a GET request with a URI that ends in a ".." when it encounters HREF="..". Since Apache doesn't tell it otherwise, dumb ol' Teleport thinks it has a file named ".." and constructs a bunch of bad relative URLs, which result in many 'Not Found' errors in our error.log. Inasmuch as this is not Apache's fault, it would be consistent to do a Redirect for a URI that has a trailing "." or ".." path component (and for trailing "./" and "../", too, for that matter) and supply the appropriate name as constructed by the getparent() routine. >How-To-Repeat: webget -head -nf www.gamers.org/docs gets 302 (correct) webget -head -nf www.gamers.org/docs/ gets 200 (correct) webget -head -nf www.gamers.org/docs/.. gets 200 (should get 302) >Fix: 1) Send a REDIRECT whenever getparent makes any changes to a uri, or 2) Send a REDIRECT whenever there is a ".." anywhere in the uri, or 3) Send a REDIRECT whenever there is a trailing ".." or "../". Pick one. :) The REDIRECT should be for the path with the ".." resolved out of it (i.e. getparent result). (A comment about this PR form: I hope a copy of this PR gets automatically e-mailed to me so I have a record of what I've submitted.) :) %0 >Audit-Trail: >Unformatted:
