Mailing List Archive

httpd patches
Hi,

Someone forwarded some patches of yours for NCSA httpd 1.3 to
us on the Apache server list.

Apache is a new httpd server, based on NCSA httpd 1.3. It is being
developed by non-NCSA folk who primarily run very busy httpd 1.3
servers and/or who want to make httpd do what they want it to.
Apache will be a public domain server.

We seem to share some common goals regarding httpd development, so
we'd like to invite you to join us. There's a mailing list
new-htttpd@hyperreal.com
which is very active - expect dozens of mail messages a day.

See http://www.hyperreal.com/httpd/arch/ for an archive of
the mail.

To subscribe, send mail to new-htttpd-request@hyperreal.com with
the word "subscribe" somewhere in the body.

So, if you're interested, we'll read from you sooner or later, otherwise,
watch out for a release of Apache, because it should fix some of the
problems you found, as well as a few you didn't.

To find out more about Apache, see
http://www.hyperreal.com/httpd/


regards,
rob, on behalf of the Apache group.


PS. Apache has not been formally annouced yet, so please keep it that way.
Re: httpd patches [ In reply to ]
Hello, guys!
>Apache is a new httpd server, based on NCSA httpd 1.3. It is being
>developed by non-NCSA folk who primarily run very busy httpd 1.3
>servers and/or who want to make httpd do what they want it to.
>Apache will be a public domain server.
What do NSCA people think of it? If there're any left? Looks like most of
them just moved to Netscape. Well, just wondering...
>
>We seem to share some common goals regarding httpd development, so
>we'd like to invite you to join us. There's a mailing list
> new-htttpd@hyperreal.com
>which is very active - expect dozens of mail messages a day.
Wow! I don't think I'll be able to anticipate that actively, though hope
can contribute some little penny...
>
>See http://www.hyperreal.com/httpd/arch/ for an archive of
>the mail.
>>It lookst to me like we already have patches for all of the problems he
>>points out except the first. (Note that his solution there isn't complete;
>>/~foo URLs still will check for /home/.htaccess-type files on the way down
>>to the user's home directory,
NO, IT WON'T! At least not with NCSA 1.3: for cycle takes care of that.
>>which means that not only do they waste time,
>>but access is gratuitously denied if FollowSymLinks is off at that level
>>in the hierarchy).
??? Though note that under Solaris 2.x /home/* aren't symlinks anymore, but
real mount points.
>
>To subscribe, send mail to new-htttpd-request@hyperreal.com with
>the word "subscribe" somewhere in the body.
I'm in for now. Let's see how it goes.

Andy.
Re: httpd patches [ In reply to ]
From: appro@fy.chalmers.se (Andy Polyakov)

What do NSCA people think of it? If there're any left? Looks like most of
them just moved to Netscape. Well, just wondering...

NCSA hired new people. A few of them are even on our list --- you may
be hearing from them. (Incidentally, they also have a new httpd
release which is currently in limited beta. Both the new NCSA release
and Apache address the initgroups bug and the single-character reads).

NO, IT WON'T! At least not with NCSA 1.3: for cycle takes care of that.

Hmmm... as I read the code, it will start checking for .htaccess files
in *subdirectories* of the directory named by the longest initial
substring which matches some <Directory> directive in access.conf (or
DocumentRoot --- but that may be redundant). (Whew!)

So, if every user home directory is a subdirectory of some other
directory named in access.conf, then httpd won't waste time walking
from root to those home directories. However, if some users have home
directories elsewhere (and at my site, they do), it will go straight
down the root, hitting the automounter paths (among others).

Did I get that right?

rst
Re: httpd patches [ In reply to ]
>
> NO, IT WON'T! At least not with NCSA 1.3: for cycle takes care of that.
>
> Hmmm... as I read the code, it will start checking for .htaccess files
> in *subdirectories* of the directory named by the longest initial
> substring which matches some <Directory> directive in access.conf (or
> DocumentRoot --- but that may be redundant). (Whew!)
??? NCSA httpd 1.3 always(!) starts searching .htaccesses from /. At
least with default access.conf... So as apache_0.4, just checked. What
have you got in access.conf?
>
> So, if every user home directory is a subdirectory of some other
> directory named in access.conf, then httpd won't waste time walking
> from root to those home directories. However, if some users have home
> directories elsewhere (and at my site, they do), it will go straight
> down the root, hitting the automounter paths (among others).
Fortunately each ~user reference leaves corresponding alias in 'a' array
in http_alias.c and that's what I use to localize .htaccess search to
users' subtrees: for cycle in tackle_on_docroot goes through aliases
and locates corresponding real path.

Andy.
Re: httpd patches [ In reply to ]
> This (a ~user reference creating a new Alias) is a terrible hack that should
> be done away with at the earliest opportunity. For a non-forking server it
^^^^^^^^^^^ is
apache going to be one? By what means? POSIX Threads or something else?
> means you would have to remember which aliases were created for a particular
> request, and free them before handling the next request.

Andy.
Re: httpd patches [ In reply to ]
Date: Tue, 4 Apr 1995 10:01:15 +0200
From: Andy Polyakov <appro@fy.chalmers.se>

> NO, IT WON'T! At least not with NCSA 1.3: for cycle takes care of that.
>
> Hmmm... as I read the code, it will start checking for .htaccess files
> in *subdirectories* of the directory named by the longest initial
> substring which matches some <Directory> directive in access.conf (or
> DocumentRoot --- but that may be redundant). (Whew!)

??? NCSA httpd 1.3 always(!) starts searching .htaccesses from /. At
least with default access.conf... So as apache_0.4, just checked. What
have you got in access.conf?

The same... I was trying to figure out your code.

Fortunately each ~user reference leaves corresponding alias in 'a' array
in http_alias.c and that's what I use to localize .htaccess search to
users' subtrees: for cycle in tackle_on_docroot goes through aliases
and locates corresponding real path.

That's the bit I was missing... just spotted it in http_alias.c. Thanks.

rst
Re: httpd patches [ In reply to ]
Hmmm... note that unmunge_name is not even necessary in principle with
Rob's code, now that it's saving the original_url...

rst
Re: httpd patches [ In reply to ]
> Fortunately each ~user reference leaves corresponding alias in 'a' array
> in http_alias.c and that's what I use to localize .htaccess search to
> users' subtrees: for cycle in tackle_on_docroot goes through aliases
> and locates corresponding real path.

>That's the bit I was missing... just spotted it in http_alias.c. Thanks.

This (a ~user reference creating a new Alias) is a terrible hack that should
be done away with at the earliest opportunity. For a non-forking server it
means you would have to remember which aliases were created for a particular
request, and free them before handling the next request.

This hack exists to make possible an even worse hack: unmunge_name().
For error reporting back to the client, httpd tries to map the offending
filename back into a URL, rather than remembering the URL the user
actually requested. It does this by reverse mapping through the Alias lists;
hence the need to 'create' an alias for ~user -> /home/user/html.
This, of course, creates a bug; what if multiple Aliases point to the
same directory? The user can be told that they cannot access a URL which is
completely different to the one they requested...

David.