Darren Garvey wrote:
On 19/08/07, Martin Wille wrote:
Darren Garvey wrote:
On 19/08/07, Martin Wille wrote: Well two protocols can't ever be used in the same program, Why is that? Can't I have a thread answering fcgi requests while another one answers scgi requests? Or even a single thread that can answer either sort of request?
Hmm, well the program has to bind to port 0, where connections are connected to.
What? Port 0?
I have looked into this and as far as I can tell, there is no efficient way to differentiate between an SCGI request and a FastCGI one: it is possible, but you would have a noticeable overhead to do this.
A program can listen() to and accept() connections from more than one port. Offering SCGI and FCGI over the same port would indeed not make a lot of sense.
The only situation I can think of where you would have a program accepting with both protocols is when you have a remote SCGI/FastCGI daemon handling requests from different HTTP servers.
It can be a single HTTP server that mounts different SCGI/FCGI server addresses at different points in its document tree. Not a very likely setup, of course. Another scenario: imagine a closed-source FCGI/SCGI hybrid server. That server can't predict whether FCGI or SCGI will be supported better on the HTTP server that gets used by a customer. The scenario you mentioned isn't uncommon, either. E.g. consider an FCGI/SCGI hybrid in a DMZ. That hybrid could get accessed from an HTTP server inside the DMZ and from another HTTP server from the intranet of a company. One could also imagine SCGI or FCGI being used by programs that do not happen to be a web server. (Supporting *CGI from the other side would be a nice addition to your library ;)
It doesn't seem sensible to use both protocols from a single server, as choosing one over the other is, IIUC, a configuration issue. In the remote daemon case, why would you not just recompile the program twice, one daemon for each protocol?
E.g. because it can make sense to implement locks inside a single application instead of using some additional IPC mechanism for them. Regards, m