Re: [mp2 API] ap_server_root() ap_server_document_root()

Stas Bekman wrote:
> Geoffrey Young wrote:
>
> > Stas Bekman wrote:
> >
> > > I have noticed that mp2 API doesn't have APIs to retrieve vhost's 
> > > server_root and document_root. I've talked to the guys at #apr, and 
> > > they suggest to add new C APIs: ap_server_root(s) and 
> > > ap_server_document_root(s)
> > >
> > > the latter is cumbersome as there is already ap_document_root(r), 
> > > they think to have ap_document_root(r, s) in 2.1.
> > >
> > > So what API should we have in mp2, stick to 
> > > ap_server_document_root(s), to be identical with httpd-2.0, or should 
> > > we fix that for our users to make it intuitive (i.e. let 
> > > document_root accept $s as well). I propose:
> > >
> > > $r->document_root; # we have it already
> > > $s->document_root; # new:
> > > $s->server_root;   # new:
> >
> >
> >
> > this option makes more sense and is more mod_perlish.  we just need to 
> > ensure that $r->document_root doesn't corrupt $s->document_root (which 
> > is probably not up to us).  that's one way to bring a frontpage server 
> > to a halt :)
>
>
> After posting this I wanted to write a C accessor, but have found out 
> that httpd's docs advise not to use ap_document_root at all, as it may 
> cause problems. I've posted a question to httpd-dev, but have received 
> no answers so far.

well, in 1.3 DocumentRoot was considered data private to core, used only for 
serving static files - nobody else had any right to depend on it (or change 
it).  the warning about mod_userdir is because mod_userdir changes the path 
of the filename, so the file is not served relative to DocumentRoot as it 
otherwise would be.

in mp1 we got around the private aspect by hooking right into core's conf 
and not using the ap_document_root() function.  the problem this exposed was 
that DocumentRoot was a per-server attribute, so if you changed it but 
didn't remember to set it back, DocumentRoot remained the altered value for 
the life of the child process, messing everybody up.  hence my remark about 
frontpage and corrupting the per-server attributes.

> As for $s->server_root, it should probably be $s->server_path, since 
> that corresponds to the ServerPath directive and the server_rec struct's 
> element.

+1

> Unrelated we can have $s->server_root, poiting at the main server's 
> root. 

point at the value of the ServerRoot directive?  that sounds ok, but I don't 
see why you'd need it as we already have server_root_relative().

> Or we can have $s->server_path do that.

I'd rather have server_path be a direct accessor - overloading functions 
doesn't really appeal to me.

--Geoff