On Thu, 28 Sep 2017, Daniel Gaspary wrote:
On Thu, Sep 28, 2017 at 6:11 PM, Michael Van Canneyt
wrote:
1. You can perfectly start the fastcgi in the debugger if you use proxy
server
or if you use mod_fastcgi confgured with fastcgiexternalserver configuration
setting. I believe nginx only uses the proxy mechanism.
Nice to know about this configuration. It seens similar to what I was
imagining, using unix sockets(optionally)
2. If that is not an option, there is also the following:
FPC contains a cgi to fastcgi request converter, you can use that to debug
the fastcgi by running it inside the debugger, and let apache forward the
request using the cgi bridge.
Could you elaborate about this bridge? Is some apache/nginx
configuration, an external tool, using some apache mod.. ??
See unit fcgigate.pp. It has some comments explaining usage.
To the outside world and the webserver, your application is a CGI app.
The cgi application simply repacks the request, sends it to the fastcgi
server, retrieves the response and sends it back to the webserver.
You just need to set the port your FastCGI app listens on. It uses a default
of 2015, so if you use that, no need to configure anything. Just compile the
gateway, drop it wherever you want/need it, and you're ready to go.
3. Third option:
FCL-Web is transparant in the sense that the code for CGI/FastCGI/Apache
module or standalone HTTP server is 100% the same. Only the used
TCustomApplication descendent differs for these 4 environments.
That means you can debug your code using the HTTP server, and switch to
using FastCGI in production. I use an {$IFDEF } in the project file to
switch the hosting environment. For the business code this is transparant.
This and the first appear to be the simpler options.
2 is also quite simple. It doesn't even need a recompile, and no need to
configure anything in the webserver.
Any chance of extend the component / create a new one, with support to
receive and send data ?
No. I don't see the need. See above, there are plenty of mechanisms to debug
a web environment.
I mean .. Not just for this case, but to have a more capable IPC.
Well, it's called SimpleIPC for a reason. The current implementation is already
far too complicated to my taste...
But there is nothing preventing us to add a 2-way communication mechanism.
but I suggest using WST or somesuch instead of SimpleIPC.
WST has lots of communication channels available,
and it's very easy to set up a simple general-purpose messaging system.
FPC really has all you need, even in 2017 ;)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
