Re: general/284: GET request with trailing ".." needs a REDIRECT

[Dean Gaudet <dg...@arctic.org>]

Actually what I meant by "making it part of the protocol" is that if we do
emit this redirect then client-writers will be more inclined to be lazy
about URL handling... which is not something I'd want to promote.  Apache
does have to handle ../ and ./ and so on.  But it's not required to emit
redirects for it.  It's probably not even required to emit the redirect
for /dir/name -> /dir/name/ but that one is usually a human error that's
hard to reprogram :)

Dean

On Sun, 30 Mar 1997, John Van Essen wrote:

> On Sat, 29 Mar 1997, Dean Gaudet <dg...@arctic.org> wrote:
> 
> >I would tend to be of the opposite opinion.  This is a client fault and if
> >we work around it on our end then it becomes part of the protocol, and
> >future clients may abuse it.  I'm sure someone else will correct me if I'm
> >wrong, but I'm pretty sure that clients are required to parse .. on their
> >end. 
> 
> I did say (indirectly) that, indeed, it *is* the client's fault:
> 
> } 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
>   ^^^^^^^^^^^
> 
> I've had at least 4 instances of this already - with more to come, no doubt.
> 
> The getparents routine already deals with trailing ".." (see below),
> so it's already part of the protocol.  I'm just asking for the redirection.
> 
> I've figured out a very simple fix.  getparents() in util.c has this:
> 
>     /* d) remove trailing xx/.. segment. */
>     if (l == 2 && name[0] == '.' && name[1] == '.') name[0] = '\0';
>     else if (l > 2 && name[l-1] == '.' && name[l-2] == '.' && name[l-3] == '/')
>     {
>         l = l - 4;
>         if (l >= 0)
>         {
>             while (l >= 0 && name[l] != '/') l--;
>             l++;
>         }
>         else l = 0;
>         name[l] = '\0';
>     }
> 
> 
> Change      l++;
> to          if (l <= 0) l++;     /* Keep "/" only if at BOL */
> 
> and the missing "/" (which was also missing on the original URI,
> I might add) will trigger the redirection in handle_dir().
> 
> Maybe I'll try this out.  After all, it only affects processing for
> URI's that we shouldn't even be getting, right?  ;)
> 
>         John Van Essen   <va...@tc.umn.edu>   <jv...@gamers.org>
> 
>