You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <co...@Apache.Org> on 1999/01/04 05:45:24 UTC
[STATUS] (apache-1.3) Sun Jan 3 23:45:22 EST 1999
1.3 STATUS:
Last modified at [$Date: 1999/01/03 13:46:16 $]
Release:
1.3.4-dev: current.
Possible release on ???
Lars volunteers as RM for dates after January 21.
1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19. Announced and released.
1.3.0: Tagged and rolled on June 1. Announced and released on the 6th.
2.0 : In pre-alpha development, see apache-2.0 repository
RELEASE SHOWSTOPPERS:
* Paul's [PATCH] Win32 device files
Message-ID: <Pi...@ecstasy.localnet>
and <00...@wolfpad.raleigh.ibm.com>
Status: Someone who knows the current status of this thing should
apply it now, since the rest of us can't test it otherwise.
* nmake compilation broken on Win95
Paul Ausbeck says the problem is that the distribution uses
%PARAM% type arguments in nmake invokations.
Message-ID: <36...@alumni.cse.ucsc.edu>
Status: patch needed since we can't test above without it
* long pathnames with many components and no AllowOverride None
Status: Marc is looking at it
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* How should an Apache binary release tarball look?
- A proposed solution is available.
See: <XF...@unix-ag.org>
<XF...@unix-ag.org>
1. The "old" way where it is just a source release tarball
plus a pre-compiled src/httpd-<gnutriple>. It is created
via the apache-devsite/binbuild.sh script which
- creates the build tree
- creates the src/Configuration file with standard modules
- runs "make"
- renames src/httpd to src/httpd-<gnutriple>
- runs "make clean"
- packs the build tree stuff together
Already known discussion points:
- should src/httpd be renamed or not because a lot
of PRs say they cannot find the httpd :-(
Status: Ralf -0, Ken +0
2. The way some other projects release binary tarballs, i.e.
a package containing the installed (binary) files.
It can be created by a script which
- creates the build tree
- runs "./configure --prefix=/usr/local/apache \
--enable-shared=remain \
--disable-module=auth_db \
--enable-suexec ..."
- runs "make install root=apache-root"
- packs the stuff together from ./apache-root only!!
Already known discussion points:
- should there be a prefix usr/local/apache in
the tarball or not? Some people think
it's useful while others dislike it a lot.
- it doesn't include the source.
- the paths don't match the original Apache style, nor the Win32
paths
- should suexec be prebuilt in a binary tarball?
Status: Ralf +1, Martin +1, Roy -1, Ken +1 (IFF source is included,
there's no usr/local/apache prefix in the tarball, AND the
old-style [common with Win32] paths are used)
3. A source release tarball with three extra directories:
lib: for the shared library object files
bin: for the httpd and support executables
man: for the man files (if desired)
as if the server was installed in those directories.
Status: Roy +1, Jim +1 (still need to define which modules
are built)
Ralf -0 (I dislike mixed source+binary tarballs)
Documentation that needs writing:
* Need a document explaining mod_rewrite/"UseCanonicalName off" based
virtualhosting. (If it exists already I can't find it easily.)
=> It still doesn't exists but I've already assembled the relevant
information and config snippets. We just have to write a
vhost-xxx.html document out of it. -- rse
Available Patches:
* Ken's default sort order for autoindexed listings
First pass for concept; maybe directive should be renamed or
syntax changed?
Message-ID: <36...@Apache.Org>
Status: Ken +1 (concept), Martin +1 (concept)
* Lars' 'binbuild' patch
Message-ID: <XF...@unix-ag.org>
Status: Lars +1
* Jim Patterson's patch to make mod_info work on Win32
Message-ID: PR#1442
Status: Lars +1 (on concept)
* Peter Greis' new '%m' CustomLog option: the time taken to serve the
request, in milli-seconds.
Message-ID: PR#2838
Status:
* Ronald Tschal�r's ap_uuencode() bugfix
Message-ID: PR#3411
Status: Lars +1 (on concept)
* Michael van Elst's patch [PR#3160] to improve mod_rewrite's
in-core cache handling by using a hash table.
Message-ID: <XF...@unix-ag.org>
Status: Lars +1, Jim +1, Ralf +1 (on concept, but because the code
change is not trivial I want to
first walk though it line by line
the next days before we commit it).
* Juan Gallego's patch to add CSH-style modifiers (:h, :r, :t, :e)
to mod_include's variable processing.
Mesage-ID: PR#3246, also available at
<http://www.physics.mcgill.ca/~juan/mod_include.patch>
Status: Ken -0 for 1.3/+0 for 2.0, Lars -0 for 1.3
* Eric Prud'hommeaux's mod_dir mods for file-level access control.
Message-ID: <Pi...@tux.w3.org>
Status: Jim -0 (The current behavior seems logical to me. If there
was more universal interest in changing it, then that would be
a different matter).
* Eric Prud'hommeaux's mods for practical negotiation with
file level access control.
Message-ID: <Pi...@tux.w3.org>
Status:
In progress:
* Marc's [PATCH] PR#3323: recursive includes
Message-ID: <Pi...@alive.znep.com>
Status: Marc +1, Jim +1 (concept)
* Needs more in-depth review *
* Ronald Tschal�r's major update of mod_digest
Message-ID: <19...@chill.innovation.ch>
Status:
* Mark Bixby's freshening up the MPE/iX port (mostly APACI)
Message-ID: <19...@spock.dis.cccd.edu>
Status: Mark says: "...currently waiting for HP to fix two OS bugs.
A fix for siglongjmp() is available and has been tested
successfully by me, but has yet to be included in a
public patch. The likely cause of the "EINTR from
fopen()" bug has been identified, but analysis on how
to fix it continues."
Needs patch:
* get_path_info bug; ap_get_remote_host should be ap_vformatter instead.
See: <Pi...@twinlark.arctic.org>
* uri issues
- RFC2068 requires a server to recognize its own IP addr(s) in dot
notation, we do this fine if the user follows the dns-caveats
documentation... we should handle it in the case the user doesn't ever
supply a dot-notation address.
* Problems dealing with .-rooted domain names such as "twinlark." versus
"twinlark.arctic.org.". See the thread containing
Message-ID: <19...@deejai.mch.sni.de> for more details.
In particular this affects the correctness of the proxy and the
vhost mechanism.
* proxy_*_canon routines use r->proxyreq incorrectly. See
<Pi...@twinlark.arctic.org>
* work around a Navigator/Mozilla bug when mod_proxy is used
(broken images).
Message-ID: <XF...@unix-ag.org>
Status: Lars' patch was vetoed. Roy and Dean think that it is
probably another buffer magic number error and should be
tested to find out and, if so, fixed like it was in core.
* ap_escape_html() always duplicates the string, even when there is
no change and the caller would be happy to use the original.
What is needed is a separate interface for "don't need a dup"
situations, like just about everywhere we use it in bvputs and
bputs calls.
Open issues:
* Redefine APACHE_RELEASE. Add another 'bit' to signify whether
it's a beta or final release. Maybe 'MMNNFFRBB' which means:
MM: Major release #
NN: Minor release #
FF: "fix" level
R: 0 if beta, 1 if final release
BB: beta number
See: <19...@devsys.jaguNET.com>
Status: Jim +1, Ben +1, Martin +1, Ralf +1
* Someone other than Dean has to do a security/correctness review on
psprintf(), bprintf(), and ap_snprintf(). In particular these routines
do lots of fun pointer manipulations and such and possibly have overflow
errors. The respective flush_funcs also need to be exercised.
o Jim's looked over the ap_snprintf() stuff (the changes that Dean
did to make thread-safe) and they look fine.
o Laura La Gassa's looked over ap_vformatter & other related code
o Martin did a "source review" as well.
o Could still use 1 or 2 more sets of eyeballs.
Status: Is this still valid??
* Paul would like to see a 'gdbm' option because he uses
it a lot.
* Maybe a http_paths.h file? See
<Pi...@valis.worldgate.com>
+1: Brian, Paul, Ralf, Martin
+0: Jim (not for 1.3.0)
* Release builds: Should we provide Configuration or not?
Should we 'make all suexec' in src/support?
+1: Brian, Jim, Ken +1 (possible suexec path issue, though)
* root's environment is inherited by the Apache server. Jim & Ken
think we should recommend using 'env' to build the
appropriate environment. Marc and Alexei don't see any
big deal. Martin says that not every "env" has a -u flag.
* Marc's socket options like source routing (kill them?)
Marc, Martin say Yes
* Ken's PR#1053: an error when accessing a negotiated document
explicitly names the variant selected. Should it do so, or should
the original URI be referenced?
* Proposed API Changes:
- r->content_language is for backwards compatibility... with modules
that may not link any longer without some minor editing. The new
field is r->content_languages. Heck it's not even mentioned in
apache-devsite/mmn.txt when we got content_languages (note the s!).
The proposal is to remove r->content_language:
Status: Paul +1, Ralf +1, Ken +1, Martin +1
- child_exit() is redundant, it can be implemented via cleanups. It is
not "symmetric" in the sense that there is no exit API method to go
along with the init() API method. There is no need for an exit
method, there are already modules using cleanups to perform this (see
mod_mmap_static, and mod_php3 for example). The proposal is to
remove the child_exit() method and document cleanups as the method of
handling this need.
Status: Rasmus +1, Paul +1, Jim +1,
Martin +1, Ralf +1, Ken +1
* Should we re-enable nagle now that we're non-buffering CGIs? See
various messages from Marc in March 98.
* TZ should not be dealt with specially any longer now that we have
"PassEnv". See
<Pi...@twinlark.arctic.org>
Jim: IMO it's too late in the game for this... I'm
sure this would cause some strange bug reports as
people's cgi-scripts no longer work correctly
("It worked just fine before I upgraded to 1.3.0")
unless we warn people in big nasty letters to add
PassEnv TZ to their config files "just in case"
and hope they do it :)
* In ap_bclose() there's no test that (fb->fd != -1) -- so it's
possible that it'll do something completely bogus when it's
used for read-only things. - Dean Gaudet
* Roy's HTTP/1.1 Wishlist items:
1) byte range error handling
* use of spawnvp in uncompress_child in mod_mime_magic - doesn't
use the new child_info structure, is this still safe? Needs to be
looked at.
* suexec doesn't understand argv parameters; e.g.
<!--#exec cmd="./ls -l" -->
fails even when "ls" is in the same directory because suexec is trying
to stat a file called "ls -l". A patch for this is available at
http://www.xnet.com/~emarshal/suexec.diff
and it's not bad except that it doesn't handle programs with spaces in
the filename (think win32, or samba-mounted filesystems). There are
several PR's to this and I don't see for security reasons why we can't
accomodate it, though it does add complexity to suexec.c.
PR #1120
Brian: +1
Win32 specific issues:
Important
* fix O(n^2) attack in mod_isapi.c ... i.e. recopy the code from
scan_script_headers_err_core.
In progress:
* Ben's ASP work... All agree it sounds cool.
* DDA's adding a tray application to the Windoze version for ease of
status/management.
<01...@caravan.individual.com>
<01...@caravan.individual.com>
Status: Ken +1, Sameer +1, Martin +1, Ben +1 (as long as
we get a single executable)
Paul: No like Win95 specific stuff
Ken: What's W95-specific about it?
Help:
* should trap ^C when running not-as-service and do proper shutdown
* should have a pretty little icon for Apache on Win32
* proxy module doesn't load on Win95. Why? Good question. PR#1462.
* Proxy cache garbage collection doesn't work. PR#1891
* "Directory /", "Directory C:/" both fail to do anything,
while "Directory *" SEGVs.
* chdir() for CGI scripts and mod_include #exec needs to be
re-implemented now that CreateProcess is being used.
* process/thread model
- need dynamic thread creation/destruction, similar to
Unix process model
- can't use WaitForMultipleObjects in the same way we
do now, since that has a limit of 64(!) objects. Grr.
PR#1665
* some errors printed by CGIs to stderr don't end up making it
to the server log unless an extra debugging message is added
after they run? (PR#1725 indicates this may not be just Win32)
* handle bugs that make it pop up errors on console, ie. segv
equiv? Can we do this? Need to make it robust.
* install
- make installshield work
- config in cvs tree?
- install docs, etc.?
- location for install
* the mutex should be critical-regions, since the current design
is creating a mess of SO calls that are unnecessary
* we don't mmap on NT. Use TransmitFile?
* CGIs
- docs on how they work w/scripts
- use registry to find interpreter?
- WTF is the buffering coming from?
- we don't have a way to make non-blocking files on NT!
* performance
* documentation:
- running the server without admin
- how CGIs work
- update README.NT
- short/long name handling
- better status page on current state of NT for users
* http_main.c hell
- split into two files?
* who should run the service? Who exactly is the "system account"?
docs say:
Localsystem is a very privileged account locally, so you shouldn't run
any shareware applications there. However, it has no network privileges
and cannot leave the machine via any NT-secured mechanism, including
file system, named pipes, DCOM, or secure RPC.
and:
A service that runs in the context of the LocalSystem account
inherits the security context of the SCM. It is not associated with
any logged-on user account and does not have credentials (domain
name, user name, and password) to be used for verification. This
has several implications: [... removed ...]
That _really_ sucks. Can we recommend running Apache as some
other user?
* need a crypt() of some sort.
- sources are easy; problem is export restrictions on DES
- if we don't do DES, can do md5
* modules that need to be made to work on win32
- mod_example isn't multithreadreded
- mod_unique_id (needs mt changes)
- mod_auth_db.c (do we want to even try this? We should have some
db of some sort... what else can we pick from under win32?)
- mod_auth_dbm.c
- mod_info.c (PR#1442 re exporting symbols for it...)
- mod_log_agent.c
- mod_log_referer.c
- mod_mime_magic.c (needs access to mod_mime API stage...)
* do something to disable bogus warnings
* rfc1413.c has static storage which won't work multithreaded
* mod_include --> exec cgi, exec cmd, etc. don't work right.
Looks like a code path that isn't run anywhere else that has
something not quite right... A PR or two on it.
* signal type handling
- how to rotate logs from command line?
(Point people to Andrew Ford's cronolog because it's "better"
than ours?)
* Currently if you double click on the conf files or the
log files you get a useless dialog offering the set of all
executables, usually after a very long pause. Ought
to stuff .conf in the registry mapping it to text.
* apparently either "BrowserMatch" or the "nokeepalive" variable
cause instability - see PR#1729.
Binaries
The goal here is to have two columns of all-Y (where applicable)
for the two stable release versions, and nothing under Old unless
the new version just doesn't work on that platform.
1.2.6 1.3.4 Old
aix_4.1 N N 1.2.5, 1.3.1
alphalinux N N 1.3.0
aux_3.1 N N 1.3.0
decalphaNT N N 1.3b6
dunix_4.0 N N 1.2.4, 1.3.0, 1.3.1
freebsd_2.1 N N 1.2.4
freebsd_2.2 N N 1.2.5
hpux_10.20 N N 1.2.5
hpux_11 N N 1.3.2
irix_6.2 N N 1.2.5
linux_2.x N N 1.2.4, 1.3.0
netbsd_1.2 N N 1.2.4
os2 N N 1.3.2
reliantunix_5.4 Y N 1.3.1
solaris N N 1.2.5, 1.3.0, 1.3.1
sparclinux N N 1.3.0, 1.3.1
sunos_4.1.x N N 1.2.5
ultrix_4.4 N N 1.2.4
win32 - N 1.3.2 (is symlink okay?)
Re: [STATUS] (apache-1.3) Sun Jan 3 23:45:22 EST 1999
Posted by Randy Terbush <ra...@Covalent.NET>.
I wanted to weigh in on the binary dist discussion to see if I can
help us with decision for release. I agree that this needs to be
resolved so we can catch up some of the binary distribution lackings.
I'll commit votes after this email discussion.
> RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>
> * How should an Apache binary release tarball look?
>
> - A proposed solution is available.
> See: <XF...@unix-ag.org>
> <XF...@unix-ag.org>
>
> 1. The "old" way where it is just a source release tarball
> plus a pre-compiled src/httpd-<gnutriple>. It is created
> via the apache-devsite/binbuild.sh script which
> - creates the build tree
> - creates the src/Configuration file with standard modules
> - runs "make"
> - renames src/httpd to src/httpd-<gnutriple>
> - runs "make clean"
> - packs the build tree stuff together
> Already known discussion points:
> - should src/httpd be renamed or not because a lot
> of PRs say they cannot find the httpd :-(
> Status: Ralf -0, Ken +0
I can see a reason to do binary only releases. Iff binary only, I see
no reason to rename the binary. It is too difficult to document if the
name is variable.
> 2. The way some other projects release binary tarballs, i.e.
> a package containing the installed (binary) files.
> It can be created by a script which
> - creates the build tree
> - runs "./configure --prefix=/usr/local/apache \
> --enable-shared=remain \
> --disable-module=auth_db \
> --enable-suexec ..."
> - runs "make install root=apache-root"
> - packs the stuff together from ./apache-root only!!
> Already known discussion points:
> - should there be a prefix usr/local/apache in
> the tarball or not? Some people think
> it's useful while others dislike it a lot.
I think that binary distributions should use the default Apache
paths. If you don't like them, then you can recompile. I think that at
some point we may have some vendor layouts available which would
install in the standard location for that platform.
> - it doesn't include the source.
Agreed.
> - the paths don't match the original Apache style, nor the Win32
> paths
> - should suexec be prebuilt in a binary tarball?
> Status: Ralf +1, Martin +1, Roy -1, Ken +1 (IFF source is included,
> there's no usr/local/apache prefix in the tarball, AND the
> old-style [common with Win32] paths are used)
Unfortunately, I think we would only create more bug reports and
problems if we don't include a compiled suexec. There is no way to
compile suexec without compiling in serverroot which is more reason to
choose a default and stick to it.
> 3. A source release tarball with three extra directories:
> lib: for the shared library object files
> bin: for the httpd and support executables
> man: for the man files (if desired)
> as if the server was installed in those directories.
> Status: Roy +1, Jim +1 (still need to define which modules
> are built)
> Ralf -0 (I dislike mixed source+binary tarballs)
I'd prefer that we make binary only releases. If they want the source,
they can grab it. Anyone wanting a precompiled binary is most likely
not interested in the source code.
-Randy
Re: mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3 23:45:22 EST 1999
Posted by Dean Gaudet <dg...@arctic.org>.
On Wed, 6 Jan 1999, Martin Pool wrote:
> Why is it necessary to copy the Directory structures for each vhost?
> Couldn't global <Directory> configs just be shared across all of them?
It isn't necessary -- and they aren't copied... or at least they're not
supposed to be that I can remember. Looking at the code it doesn't look
like it copies them, it copies pointers to the directory structures, but
doesn't copy the structures themselves.
There's essentially no "copy this dir/vhost config" primitive in the
module interface, so it'd be like totally impossible to copy things.
There's only "create a new dir/vhost config" and "merge these two
dir/vhost configs". And no, it doesn't create a new and merge to do a
"copy".
But if you use the srm.conf or access.conf files, there is some crap that
happens -- I just suggest not using them. It rereads those files for each
vhost or some other such silliness. So if the dir sections were in one of
those files, then yeah it'd be duplicated.
Dean
Re: mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3 23:45:22 EST 1999
Posted by Martin Pool <mb...@wistful.humbug.org.au>.
On Mon, Jan 04, 1999 at 07:05:16PM -0800, Brian Behlendorf wrote:
> At 04:27 PM 1/4/99 +0000, Tony Finch wrote:
> >I have a text file (below) which I'll HTMLise if you like it. A couple
> >of the examples are derived from
> >http://www.engelschall.com/pw/apache/rewriteguide/
If I understand correctly, the problem with configurations like this:
<Directory /home/mbp>
...
</Directory>
<VirtualHost 1.2.3.4:80>
ServerName mbp.victim.com
ServerRoot /home/mbp
...
</VirtualHost>
<Directory /home/cjp>
...
</Directory>
<VirtualHost 1.2.3.4:80>
ServerName cjp.victim.com
ServerRoot /home/cjp
...
</VirtualHost>
[repeated many times]
is that memory usage goes up as the product of the number of
<Directory> and <VirtualHost> configurations, because Apache copies
the Directory entries for each VirtualHost. (I remember reading a PR
about this where the answer was basically "don't do that then", plus a
suggestion to use rewrites instead.)
Why is it necessary to copy the Directory structures for each vhost?
Couldn't global <Directory> configs just be shared across all of them?
--
Martin Pool
Re: mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3
23:45:22 EST 1999
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 11:24 AM 1/5/99 +0000, Tony Finch wrote:
>Brian Behlendorf <br...@hyperreal.org> wrote:
>>This is really good; if you HTMLize it I'll commit it next to the other
>>vhost documentation.
>
>Thanks. Shall I send it to the list or to you directly?
Just send it directly, once it's in CVS people will still have a chance to
comment and change things.
>>I'm sure the #1 question people will have after they implement it is, "I
>>want to set 'Redirect /blah /blah' for a certain vhost. How do I do that
>>under this system?" which I guess the answer to is "two ways: do an
>>explicit <VirtualHost> section, or use a .htaccess in that vhost's dir."
>
>I'll include something like this too -- I think I need to make it
>clearer that mod_rewrite overrides mod_alias etc. so care needs to be
>taken with using features provided by it.
That would be great. Maybe we could even distribute a separate, modified
httpd.conf-dist, that shows what can & can't be done, a la
highperformance.conf-dist.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
History is made at night; brian@hyperreal.org
character is what you are in the dark.
Re: mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3
23:45:22 EST 1999
Posted by Tony Finch <do...@dotat.at>.
Brian Behlendorf <br...@hyperreal.org> wrote:
>Tony Finch wrote:
>>
>>I have a text file (below) which I'll HTMLise if you like it. A couple
>>of the examples are derived from
>>http://www.engelschall.com/pw/apache/rewriteguide/
>
>This is really good; if you HTMLize it I'll commit it next to the other
>vhost documentation.
Thanks. Shall I send it to the list or to you directly?
>>If there is no Host: header then the configured ServerName is used
>>instead; this can be used to provide a default virtual host which
>>might allow backwardly compatible access to the dynamic virtual
>>hosts.
>
>There are lots of hidden problems with trying to do that though;
>forcing non-'/'-rooted relative pathnames in all your HREF links is
>one, but I'm sure there are other more subtle ones, and ServerPath
>does a good job at addressing it, but still I worry about "new
>feature pressure" that such a suggestion might entail.
Yes, that should be mentioned because it's easily overlooked. I have a
sneaking suspicion that mod_rewrite could be persuaded to do something
like a dynamic ServerPath, but there are all sorts of reasons why this
isn't worth it: it requires co-operation from customers to work and
therefore it frequently won't; it causes cache pollution by causing
multiple URLs to refer to the same resource; etc.
>I don't think it'd be unreasonable to suggest instead that
>non-Host:-header browsers are just out of luck. I mean, what are we
>talking about here? netscape pre-2.0, msie pre-3.0, lynx pre-2.4,
>what else?
Broken robots, but we hardly care about them.
>I'm sure the #1 question people will have after they implement it is, "I
>want to set 'Redirect /blah /blah' for a certain vhost. How do I do that
>under this system?" which I guess the answer to is "two ways: do an
>explicit <VirtualHost> section, or use a .htaccess in that vhost's dir."
I'll include something like this too -- I think I need to make it
clearer that mod_rewrite overrides mod_alias etc. so care needs to be
taken with using features provided by it.
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
Re: mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3
23:45:22 EST 1999
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 04:27 PM 1/4/99 +0000, Tony Finch wrote:
>I have a text file (below) which I'll HTMLise if you like it. A couple
>of the examples are derived from
>http://www.engelschall.com/pw/apache/rewriteguide/
This is really good; if you HTMLize it I'll commit it next to the other
vhost documentation.
>Would it be sensible to force hostnames and ServerNames to be all
>lower case? It would make handling this sort of thing slightly simpler
>:-)
Yep, sounds good to me. Some comments...
>A couple of things need to be `faked' to make the dynamic virtual host
>look like a normal one. The most important is the ServerName, and the
>way it is determined is controlled by the UseCanonicalName directive.
>With UseCanonicalName off the ServerName comes from the contents of
>the Host: header in the request. If there is no Host: header then the
>configured ServerName is used instead; this can be used to provide a
>default virtual host which might allow backwardly compatible access to
>the dynamic virtual hosts.
There are lots of hidden problems with trying to do that though; forcing
non-'/'-rooted relative pathnames in all your HREF links is one, but I'm
sure there are other more subtle ones, and ServerPath does a good job at
addressing it, but still I worry about "new feature pressure" that such a
suggestion might entail. I don't think it'd be unreasonable to suggest
instead that non-Host:-header browsers are just out of luck. I mean, what
are we talking about here? netscape pre-2.0, msie pre-3.0, lynx pre-2.4,
what else? I can't imagine it's more than 2% of traffic this days. All
I'm addressing here is the recommendation that would be in this doc.
I'm sure the #1 question people will have after they implement it is, "I
want to set 'Redirect /blah /blah' for a certain vhost. How do I do that
under this system?" which I guess the answer to is "two ways: do an
explicit <VirtualHost> section, or use a .htaccess in that vhost's dir."
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
History is made at night; brian@hyperreal.org
character is what you are in the dark.
mass vhosting, was Re: [STATUS] (apache-1.3) Sun Jan 3 23:45:22 EST 1999
Posted by Tony Finch <do...@dotat.at>.
> 1.3 STATUS:
> Last modified at [$Date: 1999/01/03 13:46:16 $]
>
>Documentation that needs writing:
>
> * Need a document explaining mod_rewrite/"UseCanonicalName off" based
> virtualhosting. (If it exists already I can't find it easily.)
> => It still doesn't exists but I've already assembled the relevant
> information and config snippets. We just have to write a
> vhost-xxx.html document out of it. -- rse
I have a text file (below) which I'll HTMLise if you like it. A couple
of the examples are derived from http://www.engelschall.com/pw/apache/rewriteguide/
Would it be sensible to force hostnames and ServerNames to be all
lower case? It would make handling this sort of thing slightly simpler
:-)
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
This document describes various techniques for efficiently serving an
arbitrary number of virtual hosts with Apache.
Motivation
==========
These techniques are useful if your httpd.conf contains hundreds of
<VirtualHost> sections that are substantially the same, for example:
#### extract from httpd.conf
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.customer-1.com
DocumentRoot /www/hosts/www.customer-1.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-1.com/cgi-bin
</VirtualHost>
<VirtualHost 111.22.33.44>
ServerName www.customer-2.com
DocumentRoot /www/hosts/www.customer-2.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-2.com/cgi-bin
</VirtualHost>
# blah blah blah
<VirtualHost 111.22.33.44>
ServerName www.customer-N.com
DocumentRoot /www/hosts/www.customer-N.com/docs
ScriptAlias /cgi-bin/ /www/hosts/www.customer-N.com/cgi-bin
</VirtualHost>
#### end
The basic idea is to replace all of the static <VirtualHost>
configuration with a mechanism that works it out dynamically. This has
a number of advantages:
(1) Your configuration file is smaller so Apache starts faster.
(2) Adding virtual hosts is simply a matter of creating the
appropriate directories in the filesystem and entries in the DNS --
you don't need to reconfigure or restart Apache.
The main disadvantage is that you cannot have different log files for
each server; however if you have very many virtual hosts then doing
this is dubious anyway because it eats file descriptors. It's better
to log to a pipe or a fifo and arrange for the process at the other
end to distribute the logs (and perhaps accumulate statistics, etc.).
A LogFormat directive that includes %v for the virtual host makes it
easy to do this.
Overview of the technique
=========================
All of the dynamic virtual hosts will either be configured as part of
the main server configuration, or within a <VirtualHost> section. For
a simple (very uniform) setup, <VirtualHost> sections aren't needed at
all.
A couple of things need to be `faked' to make the dynamic virtual host
look like a normal one. The most important is the ServerName, and the
way it is determined is controlled by the UseCanonicalName directive.
With UseCanonicalName off the ServerName comes from the contents of
the Host: header in the request. If there is no Host: header then the
configured ServerName is used instead; this can be used to provide a
default virtual host which might allow backwardly compatible access to
the dynamic virtual hosts.
The other one is the DocumentRoot. This is used by the core module
when mapping URIs to filenames, but in this context its value only
matters if any CGIs or SSI files make use of the DOCUMENT_ROOT
environment variable. This is an Apache (NCSA?) extension to the CGI
spec and as such shouldn't really be relied upon, especially because
this technique breaks it: there isn't currently a fix.
The meat of the mechanism works via Apache's URI-to-filename
translation API phase. This is used by a number of modules:
mod_rewite, mod_alias, mod_userdir, and the core module. In the
default configuration these modules are called in that order and given
a chance to say that they know what the filename is. Most of these
modules do it in a fairly simple fashion except for mod_rewrite,
which provides enough functionality to do all sorts of sick and
twisted things (like dynamic virtual hosting).
The dynamic virtual hosting idea is very simple: use the ServerName as
well as the URI to determine the corresponding filename.
Name-based dynamic virtual hosts with mod_rewrite
=================================================
This configuration snippet implements the virtual host arrangement
outlined in the Motivation section above, but in a generic fashion.
#### extract from httpd.conf
# dynamic ServerName
UseCanonicalName Off
# splittable logs
LogFormat "%v %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon
<Directory /www/hosts>
# ExecCGI is needed here because we can't force
# CGI execution in the way that ScriptAlias does
Options FollowSymLinks ExecCGI
</Directory>
## now for the hard bit
RewriteEngine On
# a ServerName derived from a Host: header may be any case at all
RewriteMap lowercase int:tolower
## deal with normal documents first:
# allow Alias /icons/ to work -- repeat for other aliases
RewriteCond %{REQUEST_URI} !^/icons/
# allow CGIs to work
RewriteCond %{REQUEST_URI} !^/cgi-bin/
# do the magic
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1
## and now deal with CGIs -- we have to force a MIME type
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi]
# that's it!
#### end
A virtually hosted homepages system
===================================
based on <http://www.engelschall.com/pw/apache/rewriteguide/#virtuserhost>
This is an adjustment of the above system tailored for a homepages
server. Using slightly more complicated rewriting rules we can select
substrings of the hostname to use in the filename so that e.g. the
documents for www.user.isp.com are found in /home/user/.
#### extract from httpd.conf
RewriteEngine on
RewriteMap lowercase int:tolower
# allow CGIs to work -- we'll only allow standard server-wide CGIs
RewriteCond %{REQUEST_URI} !^/cgi-bin/
# check the hostname is right so that the RewriteRule works
RewriteCond ${lowercase:%{HTTP_HOST}} ^www\.[a-z-]+\.isp\.com$
# concatenate the virtual host name onto the start of the URI
# the [C] means do the next rewrite on the result of this one
RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C]
# now create the real file name
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2
# define the global CGI directory
ScriptAlias /cgi-bin/ /www/std-cgi/
#### end
Using a separate virtual host configuration file
================================================
based on <http://www.engelschall.com/pw/apache/rewriteguide/#massvhost>
This arrangement uses a separate configuration file to make the
translation from virtual host to document root completely configurable
again.
#### extract from vhost.map
www.customer-1.com /www/customers/1
www.customer-2.com /www/customers/2
# ...
www.customer-N.com /www/customers/N
#### end
#### extract from httpd.conf
# as above, then:
RewriteEngine on
RewriteMap lowercase int:tolower
# define the map file
RewriteMap vhost txt:/www/conf/vhost.map
# deal with aliases as above
RewriteCond %{REQUEST_URI} !^/icons/
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
# this does the file-based remap
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/docs/$1
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
RewriteCond ${vhost:%1} ^(/.*)$
RewriteRule ^/(.*)$ %1/cgi-bin/$1
#### end
Using more than one virtual hosting system on the same server
=============================================================
With more complicated setups, you can use Apache's normal
<VirtualHost> directives to control the scope of all the rewrite
stuff. For example, you could have one IP address for homepages
customers and another for commercial customers with the following
setup. This can of course be combined with convential <VirtualHost>
sections.
#### extract from httpd.conf
UseCanonicalName Off
LogFormat "%v %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon
<Directory /www/commercial>
Options FollowSymLinks ExecCGI
AllowOverride All
</Directory>
<Directory /www/homepages>
Options FollowSymLinks
AllowOverride None
</Directory>
<VirtualHost 111.22.33.44>
ServerName www.commercial.isp.com
RewriteEngine On
RewriteMap lowercase int:tolower
RewriteCond %{REQUEST_URI} !^/icons/
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule ^/(.*)$ /www/commercial/${lowercase:%{SERVER_NAME}}/docs/$1
RewriteCond %{REQUEST_URI} ^/cgi-bin/
RewriteRule ^/(.*)$ /www/commercial/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi]
</VirtualHost>
<VirtualHost 111.22.33.45>
ServerName www.homepages.isp.com
RewriteEngine on
RewriteMap lowercase int:tolower
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteCond ${lowercase:%{HTTP_HOST}} ^www\.[a-z-]+\.isp\.com$
RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C]
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /www/homepages/$1/$2
ScriptAlias /cgi-bin/ /www/std-cgi/
</VirtualHost>
#### end