Barry A. Warsaw
barry at digicool.com
Fri Jun 29 07:30:49 CEST 2001
>>>>> "JS" == Justin Sheehy <justin at iago.org> writes:
JS> The Apache "ScriptAlias" directive and its relations, which
JS> Mailman seems to assume will be in operation, cause some other
JS> interesting behavior.
JS> If you are using Apache and follow the INSTALL, you end up
JS> doing something like:
JS> ScriptAlias /mailman/ /home/mailman/cgi-bin/
JS> This has more of an effect than simply allowing CGI scripts to
JS> run from that directory. It also does some magic with the
JS> URLs that match that pattern. If one tries to GET, say,
JS> /mailman/listinfo/somelist, Apache does not try to run
JS> /home/mailman/cgi-bin/listinfo/somelist, but instead runs
JS> /home/mailman/cgi-bin/listinfo, and provides the rest of the
JS> URL ("somelist") to /home/mailman/cgi-bin/listinfo as an
JS> I don't believe that this is part of the CGI spec in any way.
Really? I think the CGI/1.1 "spec" (which really never got past draft
status) description of SCRIPT_NAME and PATH_INFO definitely allow for
Apache's behavior here. Although SCRIPT_NAME's calculation is
technically "implementation dependent", PATH_INFO is required to
contain the url portion from SCRIPT_NAME up to any QUERY_STRING. I
don't see anything in a quick scan of the CGI/1.2 spec that
contradicts this either.
What does thttpd actually set SCRIPT_NAME and PATH_INFO to when given
a url like http://mysite.com/mailman/listinfo/mylist?
JS> The use of this behavior makes Mailman unable to work on a
JS> simple webserver that correctly implements CGI.
I disagree. Plus if the CGI/1.1 spec is supposed to "define current
practice", I'd actually be floored if it didn't jive with Apache's
behavior, given that it's been the most popular web server for years.
More information about the Mailman-Users