[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
Web applications should be completely agnostic of the global document root.
All placement of content should be compliant with previously mentioned rules,
and not make any assumptions about the content existing in other locations,
such as /usr/local, /var/www or /srv.
Such locations are intended for use at the discretion of the local
administrator.
If possible, applications should use the web server's implementation of an "alias" directive. For example, in Apache the directive is named "Alias". For web servers that do not provide such a directive, the local administrator is responsible for placing symbolic links in the document root to make an application accessible to web-users.
To register a web application with a webserver, a package should place the
relevant webserver configuration in a file under
/etc/PACKAGE if the target web server supports drop-in
configuration via a configuration file directory (such as the Apache family of
httpds' conf.d directories) or "include" configuration.
In the case of the latter, standard Debian policy applies with respect to the
modification of the web servers' configuration files. In the case of the
former, a symbolic link should be used.
If the target web server does not support either of these configuration
mechanisms, the package in question should instead provide the configuration as
an example following standard Debian documentation
policy.
Such configuration should only be performed during installation. During upgrade web applications must not take any actions to enable or disable the registration of an application, to allow the local administrator to have ultimate control.
Unregistering a web application should be handled by removing the symbolic link
in the case of conf.d-style directories. In the case of
"include" style directives, standard Debian policy applies to
modifying web server configuration files.
During package removal, web applications that register themselves with the web server must unregister themselves.
Web packages should support registration with the system administrator's chosen httpd server under multiple ip based or name based virtual hosts.
Several methods exist for registering a web application with several virtual hosts:
The Apache module mod_env can be used to provide applications with information on where to find config files
Server environment variables such as SERVER_NAME and HTTP_HOST can be used to provide applications with enough information to find what config file/script it should use
For PHP applications under Apache, one can use "php_value auto_prepend_file" to provide configuration scripts for the application
Under no circumstance should one instance of an application interfere with another instance.
The static and dynamically interpreted content of a web application should be accessable from at or underneath http://SERVERNAME/PACKAGE The package's dynamically executed content may also be accessible from http://SERVERNAME/cgi-bin/PACKAGE
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
Webapps Policy Manual
Revision: DRAFT-1.9