Don't trust the DOCUMENT_ROOT variable. It's always only reflecting the value of
the DocumentRoot directive, which is by intention, because it's consistent.
There's no way to guess a valid value for path changes made by mod_vhost_alias,
mod_rewrite, mod_alias etc.

Thank for using Apache.

*** Bug 30755 has been marked as a duplicate of this bug. ***

This is definitely a bug.  Even with Dynamic Virtual Hosts, each website should 
have access to its DocumentRoot specified by VirtualDocumentRoot.  Without this 
feature, dynamic virtual hosts are really quite useless.

The DOCUMENT_ROOT semantics are clear. Changing them would break stuff.
We could add a VIRTUAL_DOCUMENT_ROOT variable for that purpose.

->Enhancement.

I am running into this as well, particularly now that more and more people are
moving to PHP and we are seeing a lot of DOCUMENT_ROOT usage that is breaking
all over the place.

The code fix is pretty easy, override it manually for each site but if there was
a VIRTUAL_DOCUMENT_ROOT the authors could start taking this into account.

*** Bug 28561 has been marked as a duplicate of this bug. ***

Push this enhancement request to HEAD, since it is very unlikely to happen on 1.3.

I bumped into this bug again, now in apache 1.3.33. 

I have been trying to work around it in an older version, using mod_rewrite, but
it just won't modify DOCUMENT_ROOT.

Question : if VirtualDocumentRoot is in fact [actual end result] doing the same
thing as DocumentRoot, but for a mapping scheme instead of a static path. 
So why doesn't mod_vhost_alias with this directive give us the correct answer? 
Because as someone said earlier, without this, the whole module is pretty much
useful just for static sites with no, or minimal scripting. 
And a lot of drag from cgi developers in my vhosts. 

Had mod_rewrite had write access to this variable, I could've worked around the
bug directly a looong time ago, but it doesn't. 

So, sadly, I just have to scrap the "motivation behind mod_vhost_alias" as in
the docs, and go back to my pile of virtualhosts, all statically typed :(

Another VRITUAL_DOCUMENT_ROOT directive ? 
I really suggest setting DOCUMENT_ROOT to the proper value. 

I did build a mod_rewrite hack once, creating some sort of mass vhosts and used
it to create another ENV variable to specify the proper document root as
generated by mod_rewrite. 
Since such a "dirty hack" can be done in mod_rewrite, I really don't see the
point in porting the "dirty hack" into the server itself. 

Ok, so here is an example derived from the mass virtual hosts example using
mod_rewrite : 

dirty hack to set the proposed VIRTUAL_DOCUMENT_ROOT using mod_rewrite instead
of mod_vhost_alias : 
================================================================================


    <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteLog /var/log/apache/somesite/vhosts-rewrite.log
        RewriteLogLevel 1
        RewriteMap lowercase int:tolower

        # skip global aliases
        RewriteCond %{REQUEST_URI} !/^icons/
        RewriteCond %{REQUEST_URI} !/^manual/

        RewriteCond ${lowercase:%{SERVER_NAME}} ^[a-z0-9-]+\.vhosts\.somesite$
        RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]
        RewriteRule ^([a-z0-9-]+)\.vhosts\.somesite/(.*)$
/www/vhosts.somesite/$1/$2 [C,E=VIRTUAL_DOCUMENT_ROOT:/www/vhosts.somesite/$1]
    </IfModule>
================================================================================

and we get : 
SERVER_NAME = test.vhosts.somesite
DOCUMENT_ROOT = /www/vhosts.somesite 
(this was configured in a virtualhost containing the above)
VIRTUAL_DOCUMENT_ROOT = /www/vhosts.somesite/test
(by mod_rewrite)

I know I should just stay out of this, but in response to this quote: "without
this, the whole module is pretty much
useful just for static sites with no, or minimal scripting"

I'm amazed, then, that so many people seem to be sucessfully scripting from
directories mapped using UserDir, Alias, RewriteRule, and even (my gosh!)
ScriptAlias.  None of these have a "correct" DOCUMENT_ROOT, if by correct you
mean something that has some relation to the location of the script.

As has been pointed out, DOCUMENT_ROOT is not, never was, and never will be a
reliable way of finding the filesystem path to web content.

Yes, I agree, aliases, vhosts etc are not useless. In fact, I use them to great
effect! Love that tool and run hundreds of sites with them. I do think that
there is significant room for improvement on this particular topic though.

The problem arises when you use 3rd party code that, even though we scream
"DOCUMENT_ROOT IS NOT RELIABLE", assume that DOCUMENT_ROOT is in fact reliable
and functions in a reasonable and intuitive manner. Many languages like PHP make
these assumptions for us (or at least encourage a development practice that
makes the assumption). I spend hours a month dealing with this, taking tech
support emails and tweaking their PHP code so that my users don't hate me. God
forbid they upgrade that tweaked script! :)

So, we are caught in the typical trap, are the DEVELOPERS right or are the
CONSUMERS right. I think the consumers are right in general. Do we force
everyone to code to standards that were enacted years ago, before reliable
virtual hosting was common or do we adapt to this new world where people are
moving exclusively towards vhosting and away from userland hosting? 

To me there are 4 solutions:

1) Screw the consumers, Purity Is Important
2) Add VIRTUAL_DOCUMENT_ROOT and not really solve anything since now everyone
has to change their code and no one will.
3) Make mod_vhost_alias do the Right Thing that consumers expect
4) Add a variable that changes DOCUMENT_ROOT between the two contexts and allow
the webserver admin to select what they believe Purity to be.

And yes, I am fully aware that I should put my time and money where my mouth is
and fix it myself but since I lack the underlying knowledge to do so and lack
the time to get the knowledge I have to defer to the experts and plead my case :)

Still gonna keep using mod_vhost_alias, its worth the pain and I spend a lot
less time fixing badly coded PHP then I do managing static vhosts! It has been
an incredible benefit to us and I can not thank the team that put it together
enough, its really been a transformative tool for our business.

John-

(In reply to comment #11)

> 
> So, we are caught in the typical trap, are the DEVELOPERS right or are the
> CONSUMERS right. I think the consumers are right in general.

Agreed. So the DEVELOPERS of the 3rd party code should really fix their code.
Or to put it the other way round their code is not and never was compatible with
virtual mass hosting and with ScriptAlias and Alias as Joshua pointed out in #10.
And we do not change the behaviour of DOCUMENT_ROOT because of purity, but
because of backward compatibility (see also
http://issues.apache.org/bugzilla/show_bug.cgi?id=28561#c6)
So why break things for people who use httpd according to the documents, for
some people who don't?

Backward compatibility is not a valid excuse, thats why I proposed the switching
mechanism. It bypasses that issue and provides a compatibility layer to work
more intuitively with software. Even a VIRTUAL_DOCUMENT_ROOT would at least let
admins do some intelligent rewriting.

Its obvious the mod_vhost_alias was not thought out in this context, why is
there so much resistance to maybe adding the variable or the switch? All other
commands understand VirtualDocumentRoot but no one thought to fix it in a
mod_vhost context.

We all know that the 3rd party developers are not going to change this as they
are not well-versed in apache and write code that runs on many webservers (thats
why they write in Perl and PHP and Java). That to me means we should do our best
to accomodate them and update vhost_alias so that it functions properly.

Its a bug, no one wants to admit it though :)

If someone else made such a fix would there even be acceptance of it by the
apache team? Or are hearts hardened and this is seen as not a bug but a 'feature'.

I'm about ready to pay a bounty to get this resolved.

Indeed, Alias, ScriptAlias, mod_rewrite and UserDir all can brake DOCUMENT_ROOT
validity. BTW, regardless of ScriptAlias, doesn't a script know where it's own
filename is (complete path)? There are other variables that state it. So a
script can know it's own whereabouts, even if aliased outside the DOCUMENT_ROOT. 

Aren't Alias, ScriptAlias, mod_rewrite and UserDir for the purpose of doing
_specific_ configurations? I mean for when you need a custom, tweaked
configuration. (oh, and with mod_rewrite you can create a workaround, I've given
the example already).

aliasing/url rewriting does give the responsability to the httpd admin for
needing/wanting a _specific_ connfiguration layout and it's his responsability
to notify his website owners about things that work and things that don't work
or work differently in the environment that he has created. [one that is not the
generic config BOTH needed and sufficient to run a website]

Since : 
<virtualhost>
 DocumentRoot ...

does set a consistent DOCUMENT_ROOT, and mod_vhost_alias is by it's mission, a
way to allow you to simplyfy your config, NOT doing some _specific_ aliasing
schemes. So why can't mod_vhost_alias give the same results as writing multiple
<virtualhost> directives? That's what it's mission is supposed to be, right?

If i do some further aliasing, that's my problem as an admin and i shuold know
what i break. 
And most often I really don't need such specific aliasing. 

If DOCUMENT_ROOT is supposed to be so useless/unreliable, what should i do to
find where my site's files are located? asume going ../ from the script path ? 

I am only sorry my knowledge of C is so limited, 'cause I would've written a
patch myself for mod_vhost_alias long ago.

(In reply to comment #13)

> 
> We all know that the 3rd party developers are not going to change this as they
> are not well-versed in apache and write code that runs on many webservers 

And use a variable that is only present on one specific webserver (httpd)?
And use a variable whose API is limited to non mass virtual hosting?

> 
> Its a bug, no one wants to admit it though :)

No it is not. We are talking abount an enhancement here.

> 
> If someone else made such a fix would there even be acceptance of it by the
> apache team? Or are hearts hardened and this is seen as not a bug but a 

Feel free to provide a patch. I cannot promise that it goes into the code base,
because

- From the discussion it seems obvious that for most of the httpd developers
this is a low priority issue.
- It depends on the way the patch solves the problem.

> 
> I'm about ready to pay a bounty to get this resolved.
> 

Thats what I love about open software. If the developers don't want to change
what you want, you can either solve it for yourself or pay somebody else to do so.

(In reply to comment #13)

> Its obvious the mod_vhost_alias was not thought out in this context, why is
> there so much resistance to maybe adding the variable or the switch? All other
> commands understand VirtualDocumentRoot but no one thought to fix it in a
> mod_vhost context.

All other commands certainly do not "understand" VirtualDocumentRoot.  This
directive maps only the filesystem location of the response.  I frequently see
requests to make this or that directive interpolate VirtualDocumentRoot-style,
but usually there is a better way to accomplish the same thing.

> If someone else made such a fix would there even be acceptance of it by the
> apache team? Or are hearts hardened and this is seen as not a bug but a 'feature'.

Patches are always welcome but are also subject to normal Apache review rules. 
I can certainly say that a patch that changes the default behavior of
DOCUMENT_ROOT is very unlikely to be accepted.  Something that creates a
VIRTUAL_DOCUMENT_ROOT is somewhat more likely to get in.

Created attachment 17663 [details]
set document root with mod_vhost_alias

This has been causing problems for me with PHP.  I wrote a patch for
mod_vhost_alias.c to dynamically set document_root.  The changed behavior is
controlled by setting SetVirtualDocumentRoot to "on" or "true".  Patch is
attached.

(In reply to comment #17)
> Created an attachment (id=17663) [edit]
> set document root with mod_vhost_alias
> 
> This has been causing problems for me with PHP.  I wrote a patch for
> mod_vhost_alias.c to dynamically set document_root.  The changed behavior is
> controlled by setting SetVirtualDocumentRoot to "on" or "true".  Patch is
> attached.

Nice one, I personally believe that functionality should be included in
mod_vhost_alias.c - enabling it with a new directive (SetVirtualDocumentRoot) is
a great idea, so it does not mess with document_root when not expected to, but
can be told to do so.

I understand the Apache developers resistance to including this functionality as
document_root should not be relied upon to give the correct path if
mod_alias/mod_rewrite etc have done some funky magic. However, the fact remains
that there's a LOT of scripts out there which do rely on it, and for most users,
 the behaviour they expect (the Right Thing) is for document_root to be set to
whatever document_root was decided upon by mod_vhost_alias.c.

The patch didn't work for me, for Apache 2.2.2 - looks like
vhost_alias_interpolate has been changed since you wrote your patch.  I'll
manually apply the changes to that hunk and regenerate the patch and attach it
shortly.

Created attachment 18634 [details]
set document root with mod_vhost_alias from Apache 2.2.2

original patch didn't take on my mod_vhost_alias.c from Apache 2.2.2, so I
manually fixed the rejects and generated a new patch, attached.  Hope it's of
use to someone :)

this issue breaks software such as "wordpress" (and probably many other 
frameworks) which might explain why VirtualDocumentRoot is not used very much 
in hosting environments.

I *love* the idea of VirtualDocumentRoot-- it makes configuration tons 
easier.. but if it breaks other software, I have to go back to 
the "traditional" mass virtual hosting directives.

honestly, a new variable (VIRTUAL_DOCUMENT_ROOT) could be added, but then all 
of the wordpress instances deployed on the internet would have to be updated 
to use the new variable.

Add Zend Framework to the list of popular apps that can't be run properly with
the current state of DocumentRoot. At least add a VirtualDocumentRoot variable
so that we could manually fix the apps ourselves.

(In reply to comment #20)
> this issue breaks software such as "wordpress" (and probably many other 
> frameworks) which might explain why VirtualDocumentRoot is not used very much 
> in hosting environments.
> 
> I *love* the idea of VirtualDocumentRoot-- it makes configuration tons 
> easier.. but if it breaks other software, I have to go back to 
> the "traditional" mass virtual hosting directives.
> 
> honestly, a new variable (VIRTUAL_DOCUMENT_ROOT) could be added, but then all 
> of the wordpress instances deployed on the internet would have to be updated 
> to use the new variable.
> 

*** Bug 43128 has been marked as a duplicate of this bug. ***

Please, please, PLEASE fix this. The whole purpose of mod_vhosts_alias is to compress many VirtualHost 
containers that are identical (save for the DocumentRoot and ServerName) into a few simple directives.

This works great except for the fact that the resulting virtual hosts are NOT the equivelent of their hard 
coded equivalents because the DOCUMENT_ROOT variable is not adjusted to the VirtualDocumentRoot.

If this is not considered a "bug" then at the very least it seems mod_vhost_alias is not "fit for purpose", as 
the equivalent VirtualHost containers from the documentation are actually not equivalent.

(In reply to comment #1)

I think the developers of mod_vhost_alias may be missing a few important points.  Here is my opinion on the situation, and some things to take into consideration:

* There are "developers" of apache, there are users of apache (the administrators who install it), and then there are developers of web solutions that run on Apache. Though there are certainly some individuals that wear all three hats, the underlying expectation should be that they would all be different people who are not reliant on one another
* DOCUMENT_ROOT has no behavior. It is just an environment variable that is set according to the behavior of a directives and their parameters
* Setting a VIRTUAL_DOCUMENT_ROOT environment variable is useless, because it still requires users of the system to recode. And this fails to honor the delineation that should exist (or should be offered) between a web server administrator and the developer who builds apps to run on it.
* The DocumentRoot parameter has never done anything but establish the static base from which customizations to the filesystem/URL namespace could occur through the use of mod_userdir, mod_alias, mod_rewrite, etc. This is true regardless of context (whether Server or VirtualHost)
* VirtualDocumentRoot is intended as replacement to DocumentRoot, for which the only difference is the inclusion of a language the can be used to dynamically determine where the aforementioned static base of files is. It should otherwise behave in the same manner as that which it is to replace.

I think that developers often get caught up in semantics of code and functional behavior in a way that easily overlooks what "should be done." That VirtualDocumentRoot does not set the DOCUMENT_ROOT variable is by design, however, this is incorrect design. The semantics as to whether this is a bug is up to you, but this issue is no less deserving of  "enhancement" than it is a "major" one which prevents it from fulfilling its intended duty. Developers of apps should not have to recode. Administrators should have the freedom to structure their hosting environment how they see fit whenever possible.

In conclusion: VirtualDocumentRoot should set DOCUMENT_ROOT to the interpolated directory.

I love this thread, it comes up every few months! Since the developers are taking a pretty hard line on this would it be possible to get the patch in Comment #19 from David validated and included as a compile time option

./configure --enable-vhost-dir-as-documentroot

That would solve a lot of issues.

John-

(In reply to comment #24)
> Developers of
> apps should not have to recode. Administrators should have the freedom to
> structure their hosting environment how they see fit whenever possible.
> In conclusion: VirtualDocumentRoot should set DOCUMENT_ROOT to the interpolated
> directory.

> * Setting a VIRTUAL_DOCUMENT_ROOT environment variable is useless, because it
> still requires users of the system to recode.

Except the way it is now, it is not possible for me, as a developer, to get the information "I must have". Simply can not be done.

I use this for all users home directory (just the one vhost for 200,000 customers)
    VirtualDocumentRoot "/export/cgi/%-1/%-2.-1/%-2.-2/%-2+/"

The suggestion above to "yet again" create the hash with mod_rewrite, just so I can set a DocumentRoot, is not maintainable, and rather risk-prone.

Even though "VIRTUAL_DOCUMENT_ROOT" is undesirable, it at least gives me _one possible way_ to set the real "ROOT" for the scripts/users home etc. Even to buy me time while you guys argue over semantics.

Which leaves me, and probably others, with patching Apache, which will further complicate future support, debugging, and delay any upgrade for security patches, bringing down the reputation of Apache. 

Seriously, do something about it please :)

I've worked around this bug by creating a file with the following:

<?php 
$_SERVER['DOCUMENT_ROOT'] = str_replace($_SERVER['SCRIPT_NAME'],"",$_SERVER['SCRIPT_FILENAME']); 
?>

And I use:

<VirtualHost 123.123.123.123>
VirtualDocumentRoot /path/to/sites/
...
php_admin_value auto_prepend_file /path/setdocroot.php
</VirtualHost>

Also - this should work in a .htaccess file (untested):

php_flag auto_prepend_file /path/setdocroot.php

(In reply to comment #11)
> To me there are 4 solutions:
> 
> 1) Screw the consumers, Purity Is Important
> 2) Add VIRTUAL_DOCUMENT_ROOT and not really solve anything since now everyone
> has to change their code and no one will.
> 3) Make mod_vhost_alias do the Right Thing that consumers expect
> 4) Add a variable that changes DOCUMENT_ROOT between the two contexts and allow
> the webserver admin to select what they believe Purity to be.

In fact it`s a really good and simple solution for future in apache style.
Unfortunately, I cant understand why apache developers don`t want to do that patch quick and quite.

Apache developers must rewrite a lot of code of modules because them incompatible as matter of fact. Just try to use VirtualDocumentRoot (mod_vhost_alias) with mod_rewrite or mod_vhost with mod_ssl. They write mod_ssl_vhost_alias but not rewrite mod_vhost_alias to understand mod_ssl because back-compatibility.

2 Apache developers:
Guys. It`s a life. If you write bad code, rewrite them as fast as you can or close it, because tomorrow will be worse! Remember IE6. And if you cant understand me: all hates IE now, and not only version 6.

Hi,

I've had the same problem :

I wanted to use VirtualDocumentRoot directive but because it doesn't set accordingly the 'DocumentRoot' variable in cgi scripts then it's quite "useless" to me : a RewriteRule/rewritemap can handle the same work as far as i see -- so I'm asking what brings the VirtualDocumentRoot that mod_rewrite has not already :-?

For now I'm using the workarround given by Kial but I'm not sure it'll fit all my needs (that is I'm not sure some 3rd party applications don't use somewhere the variable)..

It would be more than appropriate to have the proposed patch implemented into mod_vhost_alias imho.

Grégory.

Another solution is to satisfy feature request "change DOCUMENT_ROOT via mod_rewrite":
http://www.techlists.org/archives/web/apache-users/2002-07/msg01360.shtml
http://www.techlists.org/archives/web/apache-users/2002-07/msg01379.shtml

Currently mod_rewrite's directive "RewriteRule <src> <target> [E=DOCUMENT_ROOT:<desired value>]" creates environment variable 'REDIRECT_DOCUMENT_ROOT' if <target> is redirected by other directives; else it has no effect, DOCUMENT_ROOT is overwritten by Apache.

Let's suppose that setting of environment variable DOCUMENT_ROOT by mod_rewrite will be processed in new special way (all other env. variables should not be affected): Apache changes its inner DOCUMENT_ROOT for current request to the value set by mod_rewrite, and corrects DOCUMENT_ROOT-relative paths (PATH_INFO, SCRIPT_NAME). Both inner Apache settings & corresponding environment variables should be corrected. If correction fails - return 500 Internal Server Error.

Advantages of such solution:
1. Very small backward compatibility issue.
If somebody tried to set DOCUMENT_ROOT by mod_rewrite, failed, but launched his experiment to production server(s) - he will have compatibility issue.
So to be affected, one must have done very atypical & silly thing.

2. Administrators will be able to set correct DOCUMENT_ROOT value for VirtualDocumentRoot-s in configuration files,

3. Administrators & hosting customers with limited rights will be able to create subdomains by mod_rewrite.
Currently this great Apache & mod_rewrite feature is not perfect: everything can be tuned (there are some tricks) except correcting DOCUMENT_ROOT.
Kial's workaround is good for PHP scripts, but f.e. doesn't solve issue with listing of directory's content within subdomain with "Options +Indexes" (example: http://naobum.fedushin.ru/ ).

This is without question a bug (it is not the desired behavior to have mod_rewrite and other modules NOT work with mod_vhost_alias).  The question is whether it is a bug in core apache or the users of it (ex: mod_rewrite and others).  This in essence breaks mod_rewrite while using mod_vhost_alias.  Yes it can be worked around using RewriteBase but this is only allowed in the .htaccess file (per site not en masse) and is a cludge to fix the real issue (not getting a proper DOCUMENT_ROOT automatically).

Seeing as this is a bug affecting many users (look at the number of commentsplus it affects almost all drupal, wordpress and other framework sites that use mod_rewrite to make "clean URLs") I suggest several approaches below in order of recommendation (#1 is preferred approach):
1. Allow the DocumentRoot directive to take variables so that it can be set dynamically for things like mod_vhost_alias.  This keeps the definition of DOCUMENT_ROOT unchanged but allows mod_vhost_alias users to set it properly.  I don't see how anyone looses with this solution and since it is specifically set shouldn't cause any backward compatibility issues.
2. Allow the option to change the way apache core defines DOCUMENT_ROOT to use VirtualDocumentRoot if there is no DocumentRoot directive.  This is in essence the patch someone from comment #19 if I understand correctly.  This is basically providing a way of evolving DOCUMENT_ROOT to support a more dynamic environment.  Having it implemented as a variable would minimize backward compatibility issues and allow for a smooth transition to the "newer expanded definition of DOCUMENT_ROOT".  I imagine eventually this switch will be on by default for almost all sites if this route is taken.
3. Do not change the core at all and transfer this bug to EVERY apache module that uses DOCUMENT_ROOT so that they implement using VIRTUAL_DOCUMENT_ROOT (or whatever variable it sets) if DOCUMENT_ROOT is not set.  This will be lots more coding and seems to be basically punting the issue.  It will also take considerably longer to get everything working properly since code needs to be changed in many modules.  I truly hope this is not the suggestion taken but if the view is nothing is wrong in core and this is just a scripter issue then ALL the apache modules that use DOCUMENT_ROOT should be updated to check for VIRTUAL_DOCUMENT_ROOT.  Of course mod_vhost_alias will need to be modified to set VIRTUAL_DOCUMENT_ROOT as well.

To the Devs reviewing this comment:
Many MANY people really want SOME resolution to this issue and it DOES affect a lot of users.  Please read these suggestions with an open mind and help us get SOME resolution to this issue.  Suggestion #1 in particular does not require changing the definition of DOCUMENT_ROOT.  It will require core recoding on the processing of the directive but you may be able to use the VirtualDocumentRoot processing code to accomplish this without too much work. This will allow mod_vhost_alias users to set it (along with VirtualDocumentRoot at first but likely eventually completely replacing and deprecating VirtualDocumentRoot altogether) to create fully functional mass virtual hosting.

I have logs from rewriting with and without mod_vhost_alias to show how mod_rewrite is using DOCUMENT_ROOT and without it it usually loops continuously.  If you wish to see them let me know and I will attach them.

Fixed in trunk in r1132494

fixed in 2.4.1

This was flagged as Resolved and Fixed In February 2012.  I've poored all over the internet for elaboration on how to actually use the new feature described in the Revision and there is nothing explaining it anywhere

Revision r1132494 says that the DocumentRoot can now be over-ridden on a per-request basis. But there's no example or information anywhere explaining how to do it.

If someone writes some code but doesn't provide any documentation on how to use it, then I don't think the issue can be considered resolved.

Can anyone please at least append this issue with how to use the per-request setting of Document Root?  I thought maybe I could just pass the %{HTTP_HOST} variable to DocumentRoot but it doesn't work like that.

(In reply to comment #34)
> This was flagged as Resolved and Fixed In February 2012.  I've poored all
> over the internet for elaboration on how to actually use the new feature
> described in the Revision and there is nothing explaining it anywhere
> 
> Revision r1132494 says that the DocumentRoot can now be over-ridden on a
> per-request basis. But there's no example or information anywhere explaining
> how to do it.
> 
> If someone writes some code but doesn't provide any documentation on how to
> use it, then I don't think the issue can be considered resolved.
> 
> Can anyone please at least append this issue with how to use the per-request
> setting of Document Root?  I thought maybe I could just pass the
> %{HTTP_HOST} variable to DocumentRoot but it doesn't work like that.

I've develop an apache module to things like that :

http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/

I think a configuration example is better than an explanation

http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/tree/test/vhost.conf

This is used on some french hosters (~6000), enlightenment servers on the basis to get only one vhost declared.

(In reply to comment #34)
> This was flagged as Resolved and Fixed In February 2012.  I've poored all
> over the internet for elaboration on how to actually use the new feature
> described in the Revision and there is nothing explaining it anywhere
> 
> Revision r1132494 says that the DocumentRoot can now be over-ridden on a
> per-request basis. But there's no example or information anywhere explaining
> how to do it.

It's a feature for modules. There is a new ap_set_document_root() function.

> If someone writes some code but doesn't provide any documentation on how to
> use it, then I don't think the issue can be considered resolved.

The bug report was about VirtualDocumentRoot and this now sets DOCUMENT_ROOT correctly. Therefore the issue is resolved.

> Can anyone please at least append this issue with how to use the per-request
> setting of Document Root?  I thought maybe I could just pass the
> %{HTTP_HOST} variable to DocumentRoot but it doesn't work like that.

That would be a separate enhancement request.

(In reply to comment #35)
> I've develop an apache module to things like that :
> 
> http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/
> 
> I think a configuration example is better than an explanation
> 
> http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/tree/test/vhost.conf
> 
> This is used on some french hosters (~6000), enlightenment servers on the
> basis to get only one vhost declared.

I haven't looked at the module in detail, but it seems you don't use the new ap_set_document_root() function. Modifying the core's serverconfig breaks with other MPMs than prefork.

(In reply to comment #37)
> (In reply to comment #35)
> > I've develop an apache module to things like that :
> > 
> > http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/
> > 
> > I think a configuration example is better than an explanation
> > 
> > http://git.meleeweb.net/cgit.cgi/mod_virtualvalue.git/tree/test/vhost.conf
> > 
> > This is used on some french hosters (~6000), enlightenment servers on the
> > basis to get only one vhost declared.
> 
> I haven't looked at the module in detail, but it seems you don't use the new
> ap_set_document_root() function. Modifying the core's serverconfig breaks
> with other MPMs than prefork.

My original needs are for apache 2.2 and ap_set_document_root() does not seem to be present on 2.2.23 git tag.

Actually this is working with MPM worker (master has fix to reentrant functions).

This is far away from perfect.

Stefan said:
"The bug report was about VirtualDocumentRoot and this now sets DOCUMENT_ROOT correctly. Therefore the issue is resolved."

HMMMMM Maybe I missed something but I'm pretty certain I tested $_SERVER['DOCUMENT_ROOT'] in php and it wasn't matching the value set by VirtualDocumentRoot.  You're saying it should match now?

(In reply to comment #39)
> Stefan said:
> "The bug report was about VirtualDocumentRoot and this now sets
> DOCUMENT_ROOT correctly. Therefore the issue is resolved."
> 
> HMMMMM Maybe I missed something but I'm pretty certain I tested
> $_SERVER['DOCUMENT_ROOT'] in php and it wasn't matching the value set by
> VirtualDocumentRoot.  You're saying it should match now?

Yes, in 2.4.x. It is very unlikely that the fix will ever be ported to 2.2.x because it requires infrastructure that is only present in 2.4.

Lovely.  So the problem is that my brand new server setup on November 30, 2012 pulled Apache 2.2 when I ran aptitude -install apache2.  And so I toar my hair out with this problem becuase I wasn't running a recent enough version.  Why would aptitude on Debian 6 not pull Apache 2.4?

Furthermore, what must I do to force an aptitude or apt-get install to get the latest version?

Apache 2.4 is still experimental in debian 6. 

http://lists.debian.org/debian-devel-announce/2012/03/msg00013.html

Lots more info on the Googles on this. Not an apache issue.

Thanks, John.

I didn't have a proper understanding of how repositories and builds per distro worked.  One of my buddies clarified this for me.  All this trouble because I didn't understand I've got to check out everything on my distro and not just assume its all kosher.  LOL :)  A big learning lesson I won't forget.

(In reply to Kiall Mac Innes from comment #27)
> I've worked around this bug by creating a file with the following:
> 
> <?php 
> $_SERVER['DOCUMENT_ROOT'] =
> str_replace($_SERVER['SCRIPT_NAME'],"",$_SERVER['SCRIPT_FILENAME']); 
> ?>
> 
> And I use:
> 
> <VirtualHost 123.123.123.123>
> VirtualDocumentRoot /path/to/sites/
> ...
> php_admin_value auto_prepend_file /path/setdocroot.php
> </VirtualHost>
> 
> Also - this should work in a .htaccess file (untested):
> 
> php_flag auto_prepend_file /path/setdocroot.php

I found this advice the simplest. However the .htaccess file should contain something like:

	php_value auto_prepend_file webroot.php

(ie php_value, not php_flag)

I have also modified it as follows to be less intrusive on the $_SERVER variable, and to add another convenient global:

	//	webroot.php
	//	Save in same directory as .htaccess

	<?php
		$root = $_SERVER['WEB_ROOT'] = str_replace($_SERVER['SCRIPT_NAME'],"",$_SERVER['SCRIPT_FILENAME']);
	?>

Mark