Mailing List Archive

1. Remove no2slash()
2. In directory walk (or wherever we match the URL to a file) _reject_
a filename with a void path segment.

-1. This problem, if there is a problem, is in the alias code exclusively.
The directory walk code is not implicated, and I see no reason to mess with
it without due cause, at this point in the release cycle --- that being a
clear bug which has to do directly with it.

rst

At 09:37 AM 11/3/95 GMT, you wrote:
>
>Hmm, I'm not sure this is the best solution; can we guarantee that
>this won't crop up in other modules?

No.

>
>The problem is the original completely bogus no2slash(); there is no
>reason why http://host/dira//dirb/file should be the same as
>http://host/dira/dirb/file.'
>
>We already don't remove double slashes for CGI script PATH_INFO; I suggest
>that we don't remove double slashes anywhere.

Huh? I don't get it... we don't know what else could be broken, so let's
not fix anything at all? That doesn't make any sense... we should fix
what needs to be fixed, unless by fixing a hole lot of other things are
going to die.

>
>So:
>1. Remove no2slash()
>2. In directory walk (or wherever we match the URL to a file) _reject_
> a filename with a void path segment.
>
> David.
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

After looking yours over, I *think* I could live with it (probably in
preference to mine) --- I was worried in particular about // in PATH_INFO,
but you seem to have done that right. However, I'm still wondering (with
Brian, apparently) whether there really is a problem here at all... there
isn't in, at least, the default, out-of-the-box configuration.

Hey ho...

rst

>
> After looking yours over, I *think* I could live with it (probably in
> preference to mine) --- I was worried in particular about // in PATH_INFO,
> but you seem to have done that right. However, I'm still wondering (with
> Brian, apparently) whether there really is a problem here at all... there
> isn't in, at least, the default, out-of-the-box configuration.

Even though I haven't been commenting, I have been (half) paying attention.
FWIW, here's my thoughts:

1. There isn't a bug - appropriate configuration would solve the reported
problem. Putting cgi-bin in your document tree seems unwise. I suppose that
other URLs would also be able to access it (e.g. /somedir/../cgi-bin/somescript), but I haven't tried it. Also, presumably, SSIs could include them, even
with the new restrictions, which would present an internal security problem.

2. Double slashes don't currently mean anything to Apache, don't make any great
sense to me, and lead to unintuitive defeats of various useful mechanisms. It
would seem not unreasonable to ban them, pending a defined use of them, or to
convert them all to single slashes.

I don't understand the need for support of // in PATH_INFO, though.

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.

Unfotunately, David's patch *does* break something, to wit, the
following entry from my access restrictions:

<Directory /com/web/docs/xperimental/info-gateway/abs>
<Limit GET>
order deny,allow
deny from all
allow from 128.52
</Limit>
</Directory>

What's going on here is that info-gateway is a CGI script, and the
<Directory> is restricting access to invocations of it with certain
PATH_INFO. With David's patch, the restriction is ineffective, and
access to these paths is suddenly unrestricted.

This sort of thing may look a little peculiar, but it worked with NCSA
1.3, it worked with all prior Apache releases, and I don't see any
reason to break it now.

I am appending a yet *simpler* patch, which restricts translated filenames
with "//", but does allow the above to keep working. Note that mine logs
such accesses in the error log (and returns FORBIDDEN rather than NOT_FOUND);
hopefully these will make it easier to diagnose further unintended consequen-
ces (for which I will be scanning my error log).

However, I am increasingly convinced that this simply isn't worth "fixing"
--- the problem only arises with certain oddball configurations which
people can simply be told to avoid, and *any* attempt to fix it seems to
cause problems at least as severe.

Anyway, the *third* patch in the series (clean against 0.8.just-about-any):

*** http_request.c.safe Fri Nov 3 13:46:04 1995
--- http_request.c Fri Nov 3 14:10:18 1995
***************
*** 205,210 ****
--- 205,216 ----
no2slash (test_filename);
num_dirs = count_dirs(test_filename);
get_path_info (r);
+
+ if (strstr (r->filename, "//")) {
+ log_reason ("// in translated filename --- probable alias violation",
+ r->filename, r);
+ return FORBIDDEN;
+ }

if (S_ISDIR (r->finfo.st_mode)) ++num_dirs;

I don't understand the need for support of // in PATH_INFO, though.

It's useful for scripts such as CMU's WebWatcher, which take URLs in
their PATH_INFO. (You can try WebWatcher by going to http://www.cs.cmu.edu
and selecting the obvious link).

rst

On Fri, 3 Nov 1995, Robert S. Thau wrote:
> After looking yours over, I *think* I could live with it (probably in
> preference to mine) --- I was worried in particular about // in PATH_INFO,
> but you seem to have done that right. However, I'm still wondering (with
> Brian, apparently) whether there really is a problem here at all... there
> isn't in, at least, the default, out-of-the-box configuration.

I don't think any code changes are warranted at this time. Let's not
beat ourselves up over this issue.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Here is a much more concise patch that fixes the double slash problem at
it's root, instead of trying to fixup the alias module.

It simply causes any URL with // in a filename to be rejected with
404 Not Found.

David.

*** http_request.c.orig Tue Oct 10 23:06:36 1995
--- http_request.c Fri Nov 3 15:24:12 1995
***************
*** 189,195 ****
core_dir_config **sec = (core_dir_config **)sec_array->elts;
int num_sec = sec_array->nelts;
void *per_dir_defaults = r->server->lookup_defaults;
- char *test_filename = pstrdup (r->pool, r->filename);

int num_dirs, res;
int i;
--- 189,194 ----
***************
*** 202,210 ****
* for the moment, that's not worth the trouble.
*/

- no2slash (test_filename);
- num_dirs = count_dirs(test_filename);
get_path_info (r);

if (S_ISDIR (r->finfo.st_mode)) ++num_dirs;

--- 201,209 ----
* for the moment, that's not worth the trouble.
*/

get_path_info (r);
+ if (strstr(r->filename, "//") != NULL) return NOT_FOUND;
+ num_dirs = count_dirs(r->filename);

if (S_ISDIR (r->finfo.st_mode)) ++num_dirs;

***************
*** 214,220 ****
int allowed_here = core_dir->opts;
int overrides_here = core_dir->override;
void *this_conf = NULL, *htaccess_conf = NULL;
! char *this_dir = make_dirstr (r->pool, test_filename, i);
char *config_name = make_full_path(r->pool, this_dir,
sconf->access_name);
int j;
--- 213,219 ----
int allowed_here = core_dir->opts;
int overrides_here = core_dir->override;
void *this_conf = NULL, *htaccess_conf = NULL;
! char *this_dir = make_dirstr (r->pool, r->filename, i);
char *config_name = make_full_path(r->pool, this_dir,
sconf->access_name);
int j;
*** util.c.orig Tue Oct 10 23:10:23 1995
--- util.c Fri Nov 3 15:27:14 1995
***************
*** 214,219 ****
--- 214,220 ----
}
}

+ #if 0
void no2slash(char *name) {
register int x,y;

***************
*** 222,227 ****
--- 223,229 ----
for(y=x+1;name[y-1];y++)
name[y-1] = name[y];
}
+ #endif

char *make_dirstr(pool *p, char *s, int n) {
register int x,f;

> 1. Remove no2slash()
> 2. In directory walk (or wherever we match the URL to a file) _reject_
> a filename with a void path segment.
>
>-1. This problem, if there is a problem, is in the alias code exclusively.
>The directory walk code is not implicated, and I see no reason to mess with
>it without due cause, at this point in the release cycle --- that being a
>clear bug which has to do directly with it.

Well, here's my vote on your patch:
-1 overcomplicated; simpler alternative is better, particularly considering
the timing, and is available

the comment should sound familiar; you made it about 34_htgroup.

You patch is unnecesarily complicated. It adds a new routine to the
Alias module; my patch is essentially a 3-line change to http_request.c.

Your patch is an ad-hoc solution to the problem that was created by
allowing multiple slashes in a URL. Your patch does not fix the identical
(but less serious) bugs in UserDir and AddDescription, and anywhere else
that a URL is parsed.

My patch solves all these by simply disallowing URLs with repeated slashes.

After all your comments about large changes being bad just before a
1.0 release, you will have to argue very strongly to convince me that your
much larger patch is appropriate.

David.

I don't think any code changes are warranted at this time. Let's not
beat ourselves up over this issue.

So --- Brian doesn't think there's a bug, neither does Ben (item 1 of
his note on the subject was "there isn't a bug"), and I believe I now
agree as well. In the absence of a bug, I think I agree with Brian
that the question of fixes for it is moot, particularly when the
non-fixes to the non-problem have a very real potential to introduce
difficulties worse than the one they purport to solve.

(BTW, in the few hours I had it running, the "ban //" hack did bounce
a nontrivial number of people with URLs that used to work --- more
than ten distinct sites, one being an AOL proxy).

Let's just document that having cgi-bin directories under DocumentRoot
is a Really Bad Idea, and let that be the end of it.

rst

>
> >1. There isn't a bug - appropriate configuration would solve the reported
> >problem. Putting cgi-bin in your document tree seems unwise. I suppose that
> >other URLs would also be able to access it
> >(e.g. /somedir/../cgi-bin/somescript), but I haven't tried it. Also,
> >presumably, SSIs could include them, even with the new restrictions, which
> >would present an internal security problem.
>
> >2. Double slashes don't currently mean anything to Apache, don't make any
> >great sense to me, and lead to unintuitive defeats of various useful
> >mechanisms. It would seem not unreasonable to ban them, pending a defined use
> >of them, or to convert them all to single slashes.
>
> >I don't understand the need for support of // in PATH_INFO, though.
>
> Err, in which case, why support the ^ character either? (Example chosen at
> random.)

I meant a real rather than philosophical need. // is essentially meaningless
when translated to any reasonable file system (definition of reasonable left
as an exercise for the reader). I was under the impression that someone was
actually using // to mean something, and I wondered what.

>
> Let me tell a story.
>
> An http URL was defined as http://host[:port][path]
> A path is defined as concatenation of zero or more path segments, separated
> by '/'. A path segment may be _zero_ or more of a set of characters.
>
> "" /wibble /wombat/subres /wombat//subres /wibble////
>
> are all valid paths. /wombat/subres and /wombat//subres are not required
> to identify the same resource.
>
> Problem: the Unix file system does not a allow "" as the name of a file.
> Conventional behaviour _ignores_ null path segments in pathnames passed to
> the system routines; the pathnames /foo/bar and /foo//bar represent the same
> file.
>
> So, how do we map the URL semantics to the file system's semantics?
> The NCSA (& Apache 0.6.5) solution; remove null path segments from the entire
> URL. Thus http://host/wombat/subres and http://host/wombat//subres access the
> same resource.
>
> What is wrong with this?
> 1. Relative links don't work.
> If the document subres contains a link to ../index.html
> Then when accessed as http://host/wombat/subres, the link refers to
> http://host/index.html; Whereas for http://host/wombat//subres, the
> link refers to http://host/wombat/index.html.
>
> 2. CGI scripts don't get the data they expect.
> If /cgi-bin/fetch is a script then an access to
> http://host/cgi-bin/fetch/some//path
> calls the script with PATH_INFO set to /some/path
>
> 3. I don't think that documents should have multiple URLs unless the user
> wanted this.

Erm, but in point 1 your document not only has multiple URLs but it also
behaves differently according to which one is used. No doubt one could
construct a rather intriguing website like this (for instance /// would pass //
on to all relative links, which could then also have different behaviour...),
but is it helpful? Or is that what you are saying?

>
> Other solutions would be to _redirect_ the request (redirect
> http://host/wombat//subres -> http://host/wombat/subres) so that relative
> links 'work', or treat the request as asking for the access to a directory
> ("") which does not exist, and return 404 Not Found, or 403 Forbidden.
> This might optionally be not applied to the PATH_INFO that will be handled
> by a CGI script.
>
> The Apache behaviour:
>
> Apache attempts to emulate the NCSA behaviour, but without removing multiple
> slashes from PATH_INFO data. Unfortunately, it gets it _wrong_; although in
> the majority of cases it ignores void path segments, it does not always do
> so. Here are the bugs:
> * Multiple slashes defeat Alias, ScriptAlias and Redirect directives.
>
> DocumentRoot /web/docs
> ScriptAlias /cgi-bin /web/cgi-bin
>
> http://host//cgi-bin/c references the file /web/docs/cgi-bin/c
> http://host/cgi-bin/c references the script /web/cgi-bin/c
>
> This is not compatible with the NCSA behaviour, which would map both
> of these to the CGI script
>
> * Multiple slashes defeat the Userdir directive.
>
> http://host//~drtr/dir/ http://host/~drtr//dir/ http://host/~drtr/dir/
>
> all reference the _same_ file under NCSA httpd; Apache treats the first
> as a reference to /web/docs/~drtr/dir/ rather than /home/drtr/dir/
>
> Similarly, AddDescription does not work.
>
> Whether these bugs are significant is a moot point. However, they are bugs,
> and they do represent incompatibilities with NCSA, and they could catch out
> the unwary. (As has happened; the original poster had assumed that
> ScriptAlias /cgi-bin ... would mean that /documentroot/cgi-bin would not
> be accessible to the client directly.)
>
> Apache should, at the very least, be consistent in its handling of void
> path segments. I think the current NCSA behaviour is poor, and that
> such requests should be either redirected or forbidden. The clients that
> rst sees making these accesses are probably getting pagefulls of bad links.

Ah. So do I understand that you are recommending that either /a//b is
redirected (automatically) to /a/b, or it is forbidden? And what about
PATH_INFO when you've done this? Or are you saying that only the filesystem
component should be redirected?

Confused,

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.

This _is_ a bug, and should be fixed.

I have come to disagree. I see no bug here --- and certainly no reason
to incorporate "fixes" (such as either "ban //" hack) which will unduly
inconvenience current users of my site, or which unduly complicate the
code.

rst

Aram --- THERE IS NO BUG. As to the problems introduced by David's "fix",
they are caused not by pages on my site, but rather to pointers to them
elsewhere over which I have no control.

If there were a genuine bug, as in *misbehavior*, then I would be willing
to contemplate breaking those pointers to fix it. There is not. No bug,
no fix. -1.

rst

>
> This _is_ a bug, and should be fixed.
>
> I have come to disagree. I see no bug here --- and certainly no reason
> to incorporate "fixes" (such as either "ban //" hack) which will unduly
> inconvenience current users of my site, or which unduly complicate the
> code.
>

This is like the bug->feature thing that many programs go through. It's not
a feature. It is a bug, it was never ment to do what you're asking it to do.
IMHO, we should fix the bug, and figure out a way to redo your pages so they
act the same.

<Aram>

--

Aram Mirzadeh
awm@qosina.com,awm@hyperreal.com
http://www.qosina.com/~awm/

43rd Law of Computing:
Anything that can go wr
Segmentation violation -- Core dumped

>1. There isn't a bug - appropriate configuration would solve the reported
>problem. Putting cgi-bin in your document tree seems unwise. I suppose that
>other URLs would also be able to access it
>(e.g. /somedir/../cgi-bin/somescript), but I haven't tried it. Also,
>presumably, SSIs could include them, even with the new restrictions, which
>would present an internal security problem.

>2. Double slashes don't currently mean anything to Apache, don't make any
>great sense to me, and lead to unintuitive defeats of various useful
>mechanisms. It would seem not unreasonable to ban them, pending a defined use
>of them, or to convert them all to single slashes.

>I don't understand the need for support of // in PATH_INFO, though.

Err, in which case, why support the ^ character either? (Example chosen at
random.)

Let me tell a story.

An http URL was defined as http://host[:port][path]
A path is defined as concatenation of zero or more path segments, separated
by '/'. A path segment may be _zero_ or more of a set of characters.

"" /wibble /wombat/subres /wombat//subres /wibble////

are all valid paths. /wombat/subres and /wombat//subres are not required
to identify the same resource.

Problem: the Unix file system does not a allow "" as the name of a file.
Conventional behaviour _ignores_ null path segments in pathnames passed to
the system routines; the pathnames /foo/bar and /foo//bar represent the same
file.

So, how do we map the URL semantics to the file system's semantics?
The NCSA (& Apache 0.6.5) solution; remove null path segments from the entire
URL. Thus http://host/wombat/subres and http://host/wombat//subres access the
same resource.

What is wrong with this?
1. Relative links don't work.
If the document subres contains a link to ../index.html
Then when accessed as http://host/wombat/subres, the link refers to
http://host/index.html; Whereas for http://host/wombat//subres, the
link refers to http://host/wombat/index.html.

2. CGI scripts don't get the data they expect.
If /cgi-bin/fetch is a script then an access to
http://host/cgi-bin/fetch/some//path
calls the script with PATH_INFO set to /some/path

3. I don't think that documents should have multiple URLs unless the user
wanted this.

Other solutions would be to _redirect_ the request (redirect
http://host/wombat//subres -> http://host/wombat/subres) so that relative
links 'work', or treat the request as asking for the access to a directory
("") which does not exist, and return 404 Not Found, or 403 Forbidden.
This might optionally be not applied to the PATH_INFO that will be handled
by a CGI script.

The Apache behaviour:

Apache attempts to emulate the NCSA behaviour, but without removing multiple
slashes from PATH_INFO data. Unfortunately, it gets it _wrong_; although in
the majority of cases it ignores void path segments, it does not always do
so. Here are the bugs:
* Multiple slashes defeat Alias, ScriptAlias and Redirect directives.

DocumentRoot /web/docs
ScriptAlias /cgi-bin /web/cgi-bin

http://host//cgi-bin/c references the file /web/docs/cgi-bin/c
http://host/cgi-bin/c references the script /web/cgi-bin/c

This is not compatible with the NCSA behaviour, which would map both
of these to the CGI script

* Multiple slashes defeat the Userdir directive.

http://host//~drtr/dir/ http://host/~drtr//dir/ http://host/~drtr/dir/

all reference the _same_ file under NCSA httpd; Apache treats the first
as a reference to /web/docs/~drtr/dir/ rather than /home/drtr/dir/

Similarly, AddDescription does not work.

Whether these bugs are significant is a moot point. However, they are bugs,
and they do represent incompatibilities with NCSA, and they could catch out
the unwary. (As has happened; the original poster had assumed that
ScriptAlias /cgi-bin ... would mean that /documentroot/cgi-bin would not
be accessible to the client directly.)

Apache should, at the very least, be consistent in its handling of void
path segments. I think the current NCSA behaviour is poor, and that
such requests should be either redirected or forbidden. The clients that
rst sees making these accesses are probably getting pagefulls of bad links.

David.

>Unfotunately, David's patch *does* break something, to wit, the
>following entry from my access restrictions:
>
> <Directory /com/web/docs/xperimental/info-gateway/abs>
> <Limit GET>
> order deny,allow
> deny from all
> allow from 128.52
> </Limit>
> </Directory>

I never imagined anyone doing that! However, I suppose it might be useful,
so I prefer your latest patch.

>However, I am increasingly convinced that this simply isn't worth "fixing"
>--- the problem only arises with certain oddball configurations which
>people can simply be told to avoid, and *any* attempt to fix it seems to
>cause problems at least as severe.

This _is_ a bug, and should be fixed. I might not consider it a 'showstopper',
but I think it would be peverse not to fix it in 0.8.17, (or, for that matter,
any other bugs for which we have patches.)

David.

RST: THERE IS A BUG. Apache is NOT compatible with NCSA httpd in this
respect.

No there is not --- NCSA 1.3 handles Alias comparisons the same way as
the current 0.8.16 code --- by straight comparison with initial substrings.
The "ban //" hack is the one which *introduces* an incompatibility, which
is the reason I am dead set to veto it.

As to the site which has "suffered consequences" --- it was misconfigured.
PERIOD. FULL STOP.

Even if you feel compelled to make this misconfigured site "work" ---
as I do not --- it is possible to "fix" it without breaking pointers
to my site which people have come to rely on --- the first patch I
submitted accomplishes that. (NB that "security" problems come with
ScriptAlias *only*, so mucking around with other code would be an
unnecessary, and hence *highly* undersirable, complication).

rst

Then I would suggest someone to come up with a letter for initial
complainer. He wanted an answer, and I told him we would have
one for him.

<Aram>



At 10:05 AM 11/6/95 -0500, you wrote:
> RST: THERE IS A BUG. Apache is NOT compatible with NCSA httpd in this
> respect.
>
>No there is not --- NCSA 1.3 handles Alias comparisons the same way as
>the current 0.8.16 code --- by straight comparison with initial substrings.
>The "ban //" hack is the one which *introduces* an incompatibility, which
>is the reason I am dead set to veto it.
>
>As to the site which has "suffered consequences" --- it was misconfigured.
>PERIOD. FULL STOP.
>
>Even if you feel compelled to make this misconfigured site "work" ---
>as I do not --- it is possible to "fix" it without breaking pointers
>to my site which people have come to rely on --- the first patch I
>submitted accomplishes that. (NB that "security" problems come with
>ScriptAlias *only*, so mucking around with other code would be an
>unnecessary, and hence *highly* undersirable, complication).
>
>rst
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

>
> >Erm, but in point 1 your document not only has multiple URLs but it also
> >behaves differently according to which one is used. No doubt one could
> >construct a rather intriguing website like this (for instance /// would
> >pass // on to all relative links, which could then also have different
> >behaviour...), but is it helpful? Or is that what you are saying?
>
> Erm, I don't quite understand; I was listing the defects of the NCSA
> behaviour.

Ah, OK. In that case it was I that didn't understand.

> >Ah. So do I understand that you are recommending that either /a//b is
> >redirected (automatically) to /a/b, or it is forbidden?
>
> Yes.
> >And what about PATH_INFO when you've done this? Or are you saying that only
> >the filesystem component should be redirected?
>
> Yes.
>
> But the bottom line is that Apache is not even self-consistent in its handling
> of //.

It strikes me that self-consistency is not aided by the lack of a definition of
"correct" behaviour. Are there no relevant standards?

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.

>Aram --- THERE IS NO BUG. As to the problems introduced by David's "fix",
>they are caused not by pages on my site, but rather to pointers to them
>elsewhere over which I have no control.
>
>If there were a genuine bug, as in *misbehavior*, then I would be willing
>to contemplate breaking those pointers to fix it. There is not. No bug,
>no fix. -1.

RST: THERE IS A BUG. Apache is NOT compatible with NCSA httpd in this
respect. This has already caused one site to suffer consequences of
a security hole.

Users are coming to your site using 'wrong' pointers. If you have relative
links in your pages, then they are likely to getting be poor service from your
site. Is this what you want? Not that I'm suggesting that my fix would help
these people, but there IS a (separate) problem here.

David.

>Erm, but in point 1 your document not only has multiple URLs but it also
>behaves differently according to which one is used. No doubt one could
>construct a rather intriguing website like this (for instance /// would
>pass // on to all relative links, which could then also have different
>behaviour...), but is it helpful? Or is that what you are saying?

Erm, I don't quite understand; I was listing the defects of the NCSA
behaviour.

>Ah. So do I understand that you are recommending that either /a//b is
>redirected (automatically) to /a/b, or it is forbidden?

Yes.
>And what about PATH_INFO when you've done this? Or are you saying that only
>the filesystem component should be redirected?

Yes.

But the bottom line is that Apache is not even self-consistent in its handling
of //.

David.

Given that I have already submitted a patch for all the CERT-reported
problems which deals correctly with /./, and that this patch doesn't,
I don't believe it's a good choice.

Besides which --- take it from the guy who originally designed this
thing, directory_walk is very subtle stuff, and it is extremely
difficult to forsee all potential nasty consequences of changes made
there, as we have seen. I'm not bragging about this; while I think
the code is a great improvement over the corresponding portions of the
NCSA base code, it is still far from clear and simple. And no, this
does not contradict my preference for simple changes where possible
--- there is just no such thing as a simple change to directory_walk,
because of the complexity of the routine as it stands.

That may not be pleasant, but it is the reality we have to deal with.
And given that reality, I *much* prefer changes elsewhere, where
possible, particularly if it's something like a routine like no2slash,
where you can easily construct a simple, complete set of test cases,
look at the input, look at the output, and see if it worked.

If we are really going to get something out the door as 1.0 anytime
this *month* (are we even trying any more?), I would much prefer not to
mess with directory_walk.

rst

Ok, so how about the following patch; it fixes the following features of
Apache (that are mostly present in NCSA httpd)

* that multiple slashes in requests are treated as single slashes, except
in AddDescription, Alias, Redirect, ScriptAlias, UserDir

* that relative links in the document are unlikely to work

* that parsed files can include the wrong document

* that three or more slashes can defeat Directory tags

It does this by issuing a client redirect to the URL with the first occurrence
of "//" replaced by "/". This preserves the ability of the user to
write Alias /adir/perverse//link /some/dir
and still have http://host/adir///perverse//link match this alias.
It also preserves // in CGI script PATH_INFO data.

Although this patch fixes the problem of 3 or more consecutive slashes,
no2slash() should probably still be fixed in case the web admin puts
multiple slashes in configuration directives. (e.g. Alias /dir /web///dir)

The problem with /./ in a path could be fixed in a similar way.

David.

Subject: Fix problems with //
Affects: mod_mime.c
ChangeLog: Change AddType, AddEncoding and AddLanguage so that they take
multiple file extensions on a single command.

*** http_request.c.orig Tue Oct 10 23:06:36 1995
--- http_request.c Tue Nov 7 12:10:12 1995
***************
*** 205,210 ****
--- 205,223 ----
no2slash (test_filename);
num_dirs = count_dirs(test_filename);
get_path_info (r);
+
+ if (strstr (r->filename, "//")) {
+ char *t = strstr(r->uri, "//"), *ifile;
+ if (t != NULL) /* // came from client */
+ {
+ *t = '\0';
+ ifile = pstrcat (r->pool, r->uri, t+1, NULL);
+ *t = '/';
+ table_set (r->headers_out, "Location",
+ construct_url(r->pool, ifile, r->server));
+ return REDIRECT;
+ }
+ }

if (S_ISDIR (r->finfo.st_mode)) ++num_dirs;