Mailing List Archive

Apache 0.8.14 bug report (fwd)
Forwarded message:
> From webadm@info.cam.ac.uk Sat Sep 30 15:14:17 1995
> From: WWW server manager <webadm@info.cam.ac.uk>
> Message-Id: <199509302214.XAA11600@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.
>
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
>
> Forwarded message:
> > From webadm@info.cam.ac.uk Sat Sep 30 15:14:17 1995
> > From: WWW server manager <webadm@info.cam.ac.uk>
> > Message-Id: <199509302214.XAA11600@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.
> >
>

And here's a fix. If someone could put it in the patch dir, purlease (are
there any other characters we should be escaping?):

From: ben@algroup.co.uk (Ben Laurie)
Subject: Don't forget to escape # in directory listings
Affects: util.c
Changelog: Apache failed to convert # to %23 in directory listings.

*** ../../apache_0.8.14/src/util.c Tue Sep 19 17:05:00 1995
--- util.c Sun Oct 1 07:05:14 1995
***************
*** 470,476 ****
char *copy = palloc (p, 3 * strlen (uri) + 1);

for(x=0,y=0; uri[x]; x++,y++) {
! if (ind (":% ?+&",(copy[y] = uri[x])) != -1) {
c2x(uri[x],&copy[y]);
y+=2;
}
--- 470,476 ----
char *copy = palloc (p, 3 * strlen (uri) + 1);

for(x=0,y=0; uri[x]; x++,y++) {
! if (ind (":% ?+&#",(copy[y] = uri[x])) != -1) {
c2x(uri[x],&copy[y]);
y+=2;
}


--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
[# in a directory index]
> And here's a fix. If someone could put it in the patch dir, purlease (are
> there any other characters we should be escaping?):

Mmm, '?', ';', oh and '/'. Jeeezus.

They all mean something to a URL aware browser and they're all valid in UNIX.

Ay.
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
>
> [# in a directory index]
> > And here's a fix. If someone could put it in the patch dir, purlease (are
> > there any other characters we should be escaping?):
>
> Mmm, '?', ';', oh and '/'. Jeeezus.

? is already dealt with. What on Earth does ; mean? And / is most certainly
not valid in Unix (not in a filename).

>
> They all mean something to a URL aware browser and they're all valid in UNIX.
>
> Ay.
>

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
[?;/]

Wups, rong. Forget it.

Ay.
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
>
>
> > And here's a fix. If someone could put it in the patch dir, purlease (are
> > there any other characters we should be escaping?):
>
> (") maybe
>

Oh Gawd. Perhaps we should escape everything that isn't in [0-9A-Za-z._-]?

Cheers,

Ben.

--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant Fax: +44 (181) 994 6472
and Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd,
London, England.
Re: Apache 0.8.14 bug report (fwd) [ In reply to ]
> And here's a fix. If someone could put it in the patch dir, purlease (are
> there any other characters we should be escaping?):

(") maybe