[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: common, FHS-compliant, default document root for the various web servers

Sorry for the delay in replying to this. I've just re-read all the
disagreements with the original proposal and they all seem to be related
to this main counter-argument by Sean, hence I'll reply here.

On Mon, Nov 09, 2009 at 11:50:11PM +0100, sean finney wrote:
> > FWIW, I'm fine with /vendor.
> personally, beyond the aesthetically displeasing name, i'm really
> skeptical that this will accomplish anything useful.
> * most apps require extra config and splitting out of stuff into other
>   directories for fhs compliance anyway, thus requiring some level of
>   webserver configuration, meaning this adds no benefit (beyond 1 line
>   fewer in the server config).
> * this encourages a "working in unconfigured state" for packages, which
>   seems very sketchy wrt security (similarly, to apps dropping random
>   publically executable scripts in /usr/lib/cgi-bin.

I understand this problem, but I think you're shooting at the wrong
target. The advanced proposal (beside the aesthetically displeasing
name) is about standardizing a default vendor document root on disk so
that packages can install content in it, as well as defining a base URL
that maps to it.

Inherently, such a proposal applies to static content, not CGI
applications. I fail to see where lay problems about unconfigured static

So, regarding your "working in unconfigured state" I think we should
rather just be clear that CGI should not be enabled by default, if this
is actually a concern. Personally, while I understand it, I wouldn't
like carving that in stone: maintainers should be free to decide whether
their applications have a sane default that enable apps to work out of
the box or not. I easily see both apps that can work without any conf
(e.g. CGI-based doc browsers for the local machine) and apps that would
forcibly require conf (e.g. multi-intance blog engines or other

All in all, I don't see why adding a default root for static content
make things worse wrt your problems.

A couple of other misc remarks:

- Stating that those defaults should be enabled only for the localhost
  virtual host will help a lot. For web servers with no virtual host
  support we can simply state that they should not have the proposed
  vendor document root enabled by default.

- We already have a de facto default vendor dir rooted at /doc/, why
  should this be a special case? Implementing the advanced proposal
  would enable generalizing that unfortunate ad-hoc case.

Of course, thanks to all the participants for their feedback!

Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature

Reply to: