"JS" == Justin Sheehy email@example.com 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> argument. 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.