Bug#167511: New Policy for "cgi-bin" and "cgi-lib"
There is new official Debian policy regarding the use of "cgi-bin" in web
servers. The basic issue is that many webmasters expect to have this
directory available for their own use and not have it taken over by the
system to be used by the various Debian packages. This new policy should be
in complete effect by the next release of Debian.
I've started the change by reporting bugs against the various web servers
and then later, after they've had a chance to address it, I'll report bugs
against those packages that still use the old location.
To address this, we are creating a new ScriptAlias "cgi-lib" that points to
/usr/lib/cgi-bin. All Debian packages should eventually use that new
"/cgi-lib/" path in their URLs instead of the older "/cgi-bin/". This
mechanism does allow for an easy upgrade path.
When updating a web server, the new "cgi-lib" needs to be added, but any
existing definition of "cgi-bin" should be left untouched. (New installs
should set "cgi-bin" to point to "<webroot>/cgi-bin" for easy use by
webmasters.) Systems with upgraded web-servers will continue to work with
the older packages (since both "cgi-bin" and "cgi-lib" point to the same
place), thus providing a relatively transparent conversion.
For full background information, you can read bug #32263 at:
The policy change is as follows:
--- policy.sgml.orig Fri Nov 3 00:02:17 2000
+++ policy.sgml Fri Nov 3 00:18:45 2000
@@ -2949,9 +2949,20 @@
and can be referred to as
+ <p>The purpose of using <tt>cgi-lib</tt> instead of
+ <tt>cgi-bin</tt> is that most webmasters are used to having
+ <tt>cgi-bin</tt> available for their own local use, much like
+ <tt>/usr/local</tt>. Having packages use <tt>cgi-lib</tt>
+ means that no changes need to be made by the webmaster to both
+ keep what they are used to and still have access to Debian
+ <p>Web servers should include <tt>/cgi-lib/</tt> as a standard
+ ScriptAlias of <tt>/usr/lib/cgi-bin/</tt>.</p></item>
<item><p>Access to html documents</p>
( firstname.lastname@example.org )
Do, or do not. There is no "try". -- Yoda