Hacker News Reader

Comment by sippingjippers | Hacker News Reader

I remember this :) scgi, FastCGI, uwsgi, probably gunicorn has its own too.. never quite understood the obsession with inventing mini protocols once you have a persistent server process running already and can just use HTTP proxying. They're a pain in the ass to debug and no real tooling for poking at them.

View on HN

I agree -- the whole nicety of CGI is that the web server creates your application server process for you, and then you get a very simple one-request = one response interface. Lambda/Function implementations do this right, and also support multiple requests per process, so the overhead can be more manageable. People who are nostalgic for CGI ought to be running something like OpenWhisk (or using AWS Lambda), not FastCGI.

If you're going to all the trouble of creating a FastCGI service, you might as well also create an HTTP service and route to that.

One thing I like about SCGI is how easy it is to determine the request size, compared to HTTP. You can parse first few bytes to get the size of the header section. Then the first header is required to be CONTENT_LENGTH, thought I'm not sure if all servers respect that requirement. Even if some don't, CONTENT_LENGTH is still guaranteed to be present. So you need at most two memory allocations to read the entire request into memory.

'just use HTTP proxying' would require having another HTTP server. That second HTTP server would need to implement an abstraction similar of SCGI/FCGI itself, or you'd need to move the sharding into the former HTTP server to distribute the work across several backend HTTP servers.

They've all had this almost since basically prehistory (e.g. mod_proxy_lb). The process management bit not so much, but having a web server manage app server processes, that's an abstraction I could live without

Reply on news.ycombinator.com