httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@mch.sni.de>
Subject [PATCH] [FEATURE] Clickable Path Components in ftp dir header
Date Fri, 10 Oct 1997 23:48:30 GMT
Hi,

I was not satisfied with the format of the proxy module's FTP directory
listings because

* A bug in the handling of "." and ".." directory entries delivered wrong
  results for ".." if the request path contained a trailing slash.

* Every HREF contained absolute URL's, with scheme://user@password:host/path

* the looks were rather "plain" (Header just "Directory ftp://site/path")

* Failed authentication returns 500 Server Error instead of 401 Auth Required
  (to be fixed later, when all the other proxy error messages are handled
  over the central error handling)


Here's a patch that modified the following things:

1) A <!DOCTYPE> Header is now inserted at the beginning of the document to
   show we're conforming to _something_.

2) A new <HEAD><BASE HREF=> line is sent so that ftp listings for
   A new "Content-Location:" Header line is sent so that ftp listings for
   directories which were not specified with a trailing slash are handled
   correctly by the browsers. Otherwise the relative links contained in the
   HREFs would not resolve correctly. (e.g., for a "ftp://xxx/pub" dir
   listing, a relative "gnu/" resolves to "ftp://xxx/gnu" instead of
   "ftp://xxx/pub/gnu"). This was chosen in preference over an external
   redirection (to force the browser to the correct location)
   because that would have required a second external ftp access.

3) The title "Directory ftp://site/pub/some/path/or/other/" is now clickable
                        ---------- --- ---- ---- -- ----- <--clickable links
   for each path component, allowing direct navigation to any of the
   directories in the path.

4) HREFs are now relative paths (i.e. both scheme, site, and directory path
   can be omitted, resulting in much smaller documents served, and avoiding
   potentially insecure data (user@password); these are supplied for by the
   browser when it finds relative links.

5) When the directory lister detects a directory in the listing, it appends a "/"
   to its HREF, e.g., HREF="gnu/" instead of HREF=".../gnu" as before.
   This avoids the need for the Content-Location: header in most cases.

6) The proxy module "signs" the listing again. To me, this appears to
   be a useful information because it shows _where_ the listing was
   produced (in case of problems). Otherwise it's often difficult to find
   out exactly which server was misconfigured. (This would be a useful
   addition to the other outputs of the proxy module, and/or even
   the error message module).
   But now it doesn't say (as before)
     <A HREF="http://www.apache.org/">Apache-1.3b1</A>
   but (more sensible)
     Apache-1.3b1 at <A HREF="mailto:serveradmin">servername</A> Port 80

Have a nice weekend (I'm going "upcountry"),

    Martin
-- 
| S I E M E N S |  <Martin.Kraemer@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Mime
View raw message