6 ms·
This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do
by sureaboutthis 8y ago
This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.
- aasasd 8y agoYou can also just serve HTTP.
- sureaboutthis 8y agoThat has nothing to do with my question. Of course you "serve HTTP". I want to know how one interfaces with a server without CGI or fastCGI.
- aasasd 8y agoYou serve HTTP to the server. To the front-end server or the load balancer, aka ‘reverse proxy’. That's how. Both Apache and Nginx can proxy HTTP, out of the box.
- delinka 8y agoIOW, opening a socket from the routing HTTP server to an application HTTP server. That’s pretty much how FCGI works.
- aasasd 8y agoYeah, people just seemingly realized that there's nothing special about FastCGI that couldn't be done with plain http. And as a bonus, the app itself can work as a server in the dev env, and testing is simpler. (Only, CGI managed to get headers sorta right by embedding them in protocol vars and not the other way around.)
- sureaboutthis 8y agoBut I already do this and that doesn't answer the question about the difference between fastCGI and what everyone else seems to be using, but not explaining, is a method of direct integration or ability to talk with the server without CGI/fastCGI. After doing a little research, it appears this can be done by implementing or writing modules that will talk directly to server internals if I'm understanding this correctly.
- aasasd 8y agoYou don't usually need to talk to the server from the app. Pretty much the only thing needed in practice is returning an internal redirect that ends up served by another path (with error pages being variations of this). This is solved fine with an HTTP header in the response. CGI and FastCGI actually have the exact same flow of information as HTTP (to my knowledge). Anything else is either implemented on top of that, or you'll need a module reaching into internal functions.
- delinka 8y agoIf you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications. These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and Vapor. I’ve experienced C and C++ varieties. Back in the day when Apache was seriously hot, mimicking today’s architecture would have meant writing an Apache module - the app would then live within the server and no communication channel/pipe/socket/fork/spawn would be required.
- sureaboutthis 8y agoYes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?
- delinka 8y agoOk, lemme spell it out: bundling the app and the server together; that’s what’s implied.
- sureaboutthis 8y agoWhich comes back to my question. Can one do that with apache and nginx? I'm pretty sure I've seen methods for this in Apache but only the paid version of nginx. Am I wrong?
- delinka 8y agoI mentioned Apache modules in my comment. Write a module, add it to Apache’s config, your code loads with the web server. Looks like one can also write nginx modules, but I’m not familiar with nginx licensing to know if a purchase is required to use that in a commercial deployment.
- thedufer 8y agoYou don't need a server like Apache or Nginx. Your code can just bind to 80/443 directly.
- sureaboutthis 8y agoYes you can but that has nothing to do with what I asked.
- thedufer 8y agoIf you get the same answer three times but don't think any of them answer your question, maybe consider that you're the one failing to communicate.