|
Boost : |
From: Martin Wille (mw8329_at_[hidden])
Date: 2007-08-19 17:06:47
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk