Hello,
A quick scan of the archives and the FAQ didn't turn anything up, so I thought I'd ask this here.
Is anyone known to be using Mailman with thttpd? If so, are there any known gotchas or things to look out for? I can't think of a reason why it wouldn't work, but since the Mailman docs seem to assume Apache, I figured that it was worth asking before I went ahead and set up a listserver using thttpd/Mailman.
Thanks.
-Justin
"JS" == Justin Sheehy <justin@iago.org> writes:
JS> Is anyone known to be using Mailman with thttpd? If so, are
JS> there any known gotchas or things to look out for? I can't
JS> think of a reason why it wouldn't work, but since the Mailman
JS> docs seem to assume Apache, I figured that it was worth asking
JS> before I went ahead and set up a listserver using
JS> thttpd/Mailman.I've no direct experience with thttpd, but if it supports the "standard" CGI interface, it should be fine. If you do run into any gotchas (or even if it works fine), let us know and I'll add some text to the documentation.
-Barry
barry@digicool.com (Barry A. Warsaw) writes:
I've no direct experience with thttpd, but if it supports the "standard" CGI interface, it should be fine. If you do run into any gotchas (or even if it works fine), let us know and I'll add some text to the documentation.
It supports the CGI 1.1 spec. I guess I'll just set it up and give it a shot. If there's anything interesting worth reporting, I will post it here.
-Justin
Several months ago I sent mail to mailman-users when I was trying to figure out how to get Mailman to run under thttpd.
I figured it out fairly quickly, but forgot to post the answer back here. I'm doing so now, for the benefit of others who might want to run Mailman on thttpd.
I copied the cgi-bin directory from Mailman's install directory into a "mailman" subdirectory of the thttpd data directory. This could be done with symlinks, but then you'd have to turn off some of thttpd's useful security checks.
Then, I added this entry to the thttpd configuration file:
cgipat=/mailman/**
The double-asterisk is important. Without it, thttpd will not process CGI requests of the sort that Mailman expects.
That's all. Mailman has been running flawlessly for me under thttpd for over four months now.
-Justin
barry@digicool.com (Barry A. Warsaw) writes:
I've no direct experience with thttpd, but if it supports the "standard" CGI interface, it should be fine. If you do run into any gotchas (or even if it works fine), let us know and I'll add some text to the documentation.
So, it looks like there's more required than the standard CGI interface.
The Apache "ScriptAlias" directive and its relations, which Mailman seems to assume will be in operation, cause some other interesting behavior.
If you are using Apache and follow the INSTALL, you end up doing something like:
ScriptAlias /mailman/ /home/mailman/cgi-bin/
This has more of an effect than simply allowing CGI scripts to run from that directory. It also does some magic with the URLs that match that pattern. If one tries to GET, say, /mailman/listinfo/somelist, Apache does not try to run /home/mailman/cgi-bin/listinfo/somelist, but instead runs /home/mailman/cgi-bin/listinfo, and provides the rest of the URL ("somelist") to /home/mailman/cgi-bin/listinfo as an argument.
I don't believe that this is part of the CGI spec in any way.
The use of this behavior makes Mailman unable to work on a simple webserver that correctly implements CGI.
Based on a quick look at both pieces of software, I don't see a simple way to resolve this, which is really unfortunate.
Has anyone ever reported success running mailman on a webserver other than Apache (which had not simply copied Apache's ScriptAlias behavior)?
I'm going to do a bit more investigating before I give up, in any case.
-Justin
"JS" == Justin Sheehy <justin@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> 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.
-Barry
barry@digicool.com (Barry A. Warsaw) writes:
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.
You're right, it does allow it. It certainly doesn't require it, but it doesn't rule it out either. Sorry for overstating my point.
However, it seems to be more of an assumption. With a little more poking around, I'm guessing that Apache basically just kept this behavior that was in NCSA from a fairly early date. Since then, the major servers have had that behavior and people have assumed (reasonably) that it would work that way.
I'll go bother the thttpd people instead, and figure out why they don't do things that way.
What does thttpd actually set SCRIPT_NAME and PATH_INFO to when given a url like http://mysite.com/mailman/listinfo/mylist?
It doesn't matter, effectively, as it tries to run /mailman/listinfo/somelist, which of course does not exist. This is the problem that I've been describing.
-Justin
"JS" == Justin Sheehy <justin@iago.org> writes:
JS> I'll go bother the thttpd people instead, and figure out why
JS> they don't do things that way.Okay.
>> What does thttpd actually set SCRIPT_NAME and PATH_INFO to when
>> given a url like http://mysite.com/mailman/listinfo/mylist?
JS> It doesn't matter, effectively, as it tries to run
JS> /mailman/listinfo/somelist, which of course does not exist.
JS> This is the problem that I've been describing.The question is related though, because what you describe indicates that thttp would set SCRIPT_NAME to "/mailman/listinfo/somelist" and PATH_INFO to "" /if/ it could find the script.
It seems to me that thttp's behavior would require you to have a listinfo subdirectory that contains a somelist script (IIUC), and that would make it impossible to support cgi's with both /mailman/listinfo and /mailman/listinfo/somelist (as Mailman uses to give a site-wide overview of lists, and specific list information).
Seems pretty disfunctional to me. ;)
-Barry
participants (2)
-
barry＠digicool.com -
Justin Sheehy