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
content.
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
webapps).
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!
Cheers.
--
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