Apache 0.8.14 bug report (fwd)

[Rob Hartill <ha...@hyperreal.com>]

Forwarded message:
> From webadm@info.cam.ac.uk  Sat Sep 30 15:14:17 1995
> From: WWW server manager <we...@info.cam.ac.uk>
> Message-Id: <19...@cygnus.csi.cam.ac.uk>
> Subject: Apache 0.8.14 bug report
> To: apache-bugs@apache.org
> Date: Sat, 30 Sep 1995 23:14:09 +0100 (BST)
> X-Mailer: ELM [version 2.4 PL24]
> Content-Type: text
> 
> [Sorry for using mail rather than the bug report form, but I prefer to be able 
> to keep a copy of the report... 
> 
> Email address: see above or below
> Summary: server-generated index for a directory doesn't encode # as %23 in URLs
> OS: Solaris 2.4
> Extra modules: supplied agent and referer log modules
> 
> Symptoms:
> 
> If the Apache httpd is left to generate a directory page automatically (i.e.
> no default, prepared index page), and any files have names which include the
> character "#" (say foo#bar), the "#" is included in the corresponding URL as
> itself, rather than being encoded as %23. Attempting to follow the link then
> fails, since in a URL ending with "foo#bar", "#bar" is treated as a fragment
> identifier referring to a <A NAME="bar"> anchor. Thus, the client requests file
> "foo" and (unless such a file happens to exist - though not what the user asked
> for) is told that "http:...foo" doesn't exist.
> 
> Can be reproduced easily by creating a file with "#" in the name, in a 
> directory lacking a default, prepared index and then viewing the directory and 
> subsequently trying to retrieve the file. (I confirmed the problem using 
> Netscape and lynx running under LINUX as the clients, and also checked the 
> packets sent to the server to confirm that the problem was as suspected.)
> 
> Using the same URL except for manually replacing the literal # by %23 works.
> 
> [I tripped over this while investigating what turned out to be a CERN 3.0 
> server problem when running as proxy - there, properly-encoded "#"s in URLs 
> appear still to be treated as though they were fragment identifiers and get 
> stripped before they are forwarded to the target server, with consequent "not
> found" errors from the target servers. Sigh... and unlike Apache, no chance of
> that being fixed on any reasonable timescale, unless things have changed a lot
> recently.]
> 
>                                 John Line
> -- 
> University of Cambridge WWW/gopher server manager account (usually John Line)
> Send general queries to the WWW or gopher administrator addresses - 
> webmaster@ucs.cam.ac.uk or gopher-admin@ucs.cam.ac.uk.
>