Ian Bicking: the old part of his blog

FastCGI SCGI HTTP

Mark Mayo has a useful post on FastCGI and SCGI, a kind of an overview of the history. At the end, he comes out preferring HTTP with proxying. I'll throw in my two cents...

Proxying HTTP seems elegant, but I don't think it is any more elegant than FastCGI or SCGI. In reality they are almost the same; you don't lose any information mapping from HTTP to FastCGI or SCGI, and you abstract away a few things that are nice to get rid of. But only a very small number.

One thing that is brought up is the quality of the HTTP implementations. I don't think this is a big deal -- if I understand correctly, a proxied HTTP connection will be cleaned up, and you don't have to worry about the kinds of corner cases that a public production web server needs to worry about. Connections don't die that often, there's some sanity in headers, etc. Putting SimpleHTTPServer or WEBrick behind Apache is probably just fine.

What FastCGI and SCGI provide that HTTP doesn't is a clear separation of the original request and the delegated request. REMOTE_ADDR is the IP address of original request, not the frontend server, and HTTP_HOST is also the original host. SCRIPT_NAME and PATH_INFO are separated out, giving you some idea of context.

These are small issues, but they are important. Without this, you have to do double configuration on both sides of the connection, and passing through information through ad hoc techniques like headers you make up (X-Forwarded-For being a common example).

Which leads to the second issue... what can you trust? Can you trust X-Forwarded-For? Maybe. Can you trust 127.0.0.1? Probably; are you sure you remembered to set that up?

With the *CGIs you get another internal channel of communication for communicating trusted information. A common example is REMOTE_USER, the logged-in user. You don't have to sign it or go through hoops to be sure you can trust it. If it's there, you know that an upstream internal server added it.

These are small details, but I think they are useful enough to make the *CGIs worth it compared to proxying. They reduce configuration, and I hate configuration, and they help avoid insecure and ad hoc conventions for information sharing. At the same time, all three are very similar techniques, and you shouldn't read too much into the decision.

FastCGI has some more features still, particularly process management. I wish I felt like I could confidently use such features, they seem nice. But I also don't think they need to be part of the communication protocol; SCGI is a nice, simple protocol, and the process management might be best implemented separately. FastCGI's heapin' pile o' features is probably its biggest flaw.

Created 27 Apr '06

Comments:

On the other hand, depending on where you put logic, with HTTP Proxy you can do your testing directly on your server, without Apache in the picture. The fact that it does go over the network also gives you some flexability about distributing your application.

# Ken Kinder

SCGI and FastCGI can go over the network. But yes, HTTP is nice for testing. And so with WSGI you needn't choose one over the other ;)

# Ian Bicking

For me, the biggest boon to "not PHP web frameworks" has been FastCGI. Finally I can run fancy web frameworks on my $10 / month Dreamhost account rather than shelling out ~ $100 or more a month for a dedicated server, or $40 for a virtual dedicated server. I'm all for giving up root in favor of ease of administration, low cost, and a feeling of "let those dudes take care of it for me."

FastCGI is the big equalizer. As long as your FoC (Framework of Choice) supports FastCGI, you're good to go (sort of). It's very exciting to the cheapskate (me) web developer / hobbiests of the world who just want to blog about wine, their cats, or maybe bees.

# Chris McAvoy

> Finally I can run fancy web frameworks on my $10 / month Dreamhost
> account rather than shelling out ~ $100 or more a month for a
> dedicated server, or $40 for a virtual dedicated server.

Check that again. RapidVPS: $10. TekTonic VPS: $15.

> I'm all for giving up root in favor of ease of administration,
> low cost, and a feeling of "let those dudes take care of it for me."

I'm not. I'm for control and versatility. Hands off my root! ;-P

# Nicola Larosa