Re: WWW close-to-final proposal changes in response to criticism
From: Christoph Lameter <email@example.com>
> Ok. This does make more sense now. But I still do not know on what http
> address my application can depend to reach their cgi-bin and webpages.
> Is it http://host/ROM.webspace/cgi-bin/man2html for example?
CGI bin files in the ROM areas must be individually linked to
/var/web/cgi-bin. They should be accessed via http://host/cgi-bin .
Documents can be addressed using the following paths:
http://host/document -> /var/web/webspace/document
> If so then I are running into trouble with the cern-httpd
> which seems to only support one cgi-bin at http://host/cgi-bin. (Get rid
> of cern!)
Note that I said you are not required to use /var/web as your document
root. CERN web server can establish its own document root and symlink the
cgi-bin directory to where it wants it.
> If the user has to manually create symlinks in /var/web/webspace then we
> are in for a lot of trouble.
Packages would be creating those symlinks. The user may choose to remove
some of the CGI scripts installed by Debian, in which case the user would
remove the links. The user can not remove the scripts themselves, because
they live on a potentially read-only medium in /usr/lib/web/cgi-bin .
> Due to the complexity of the approach it
> will be quite difficult to explain things to people and more even to put
> it down in a policy.
No, it is really only a sentence or two to explain that the CGI scripts
that packages install must be symlinked from /usr/lib/web/cgi-bin to
/var/web/cgi-bin by the packages that install them, so that the user can
de-activate these scripts if necessary.
> The separation of cgi-bin is IMHO not necessary
> anymore with recent servers. They have advanced security features and
> can enable security for each file in a directory in the configuration file
> (ncsa, apache, roxen) or within a config file in a directory
> (wn, apache, ncsa)
This would make automatic installation of CGI scripts difficult because
there would have to be some server-specific action performed for each
and every CGI script that a package installs. This server-specific
action would have to be repeated correctly in cases such as switching
from one server to another. Automating the switch by translating the
advanced permission files of one web server to those of another is not
feasable. Thus, we must arrive at a simple means that can be understood
by all servers. Symbolic links and fixed paths are appropriate.
> I think the matter of setting up things should be left to the webserver
> since webservers have features that might remove the need for symlinks
> or symlink-trees. It is sufficient to specify where a web application can
> install its stuff and upon what html address it can rely on. The Webserver
> should cope with things beyond that.
Setting up what things? This is very unclear.
> If you specify symlinks then the development of more advanced methods to
> accomplish what we want will be stifled.
I think we are not communicating clearly. Perhaps I should re-write the proposal
before we argue about this any more.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com