Jérémy Lal <je...@edagames.com> writes: > On 31/05/2011 18:43, Russ Allbery wrote:
>> So this implies to me that spawn-fcgi should provide the virtual >> package that scripts depend on, because this is the meaningful >> interface for CGI scripts that want to run in FastCGI mode. Whether >> that then hooks to a web server on the same system or a web server on >> some other system is up to the local administrator. > note that a cgi script cannot be directly used as a fastcgi backend. > fcgi-cgi [0] is the tool to do that. But it's much better to have > implemented fcgi interface in the script (which is usually dead simple). I was thinking of Perl scripts that use CGI::Fast, which automatically does that sort of mode switching, but yes, this is in general a good point. > So there are two virtual packages now : one for the fcgi server and one > for the backend. I'm not convinced trying to define an interface for > registering the backend is such a good idea, because the only experience > i have is with spawn-fcgi. AFAIK it's well designed and serves the > purpose perfectly. Upstream is not so active but there have been no bug > reports for a while now. The interface between the script and whatever spawns it is one of those things that we may need to leave undefined right now since Debian doesn't have a great handle on some of the policy issues around configuring CGI yet (such as what scripts should be configured to run by default). > For the fcgi server configuration, it is much more interesting to do > this, and an approach like dbconfig-common (probably much simpler > actually) might be good to have. It should deal with simple cgi > configuration too, at least on the supported httpd-fcgi servers. Yeah, that makes a lot of sense. We run into the standard web server configuration problem of trying not to make assumptions about the URL namespace that the local administrator wants to expose, though. I personally would be happy to move forward with defining virtual packages in Policy for the backend that spawns the scripts and for the capability in the web server to talk to a FastCGI socket without hammering out all of the configuration details, since we're at that point moving into stuff that's underspecified in Debian as a whole anyway. I do think it would make sense to standardize in Policy, as part of the virtual package definitions, what path or directory should be used for the FastCGI sockets so that we at least have some sort of basic rendezvous set up to allow more automatic configuration later. But I haven't thought about it a lot. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb8a6apz....@windlord.stanford.edu