[selcuka]

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application.

Not entirely correct. A reverse proxy can either speak HTTP, or a different protocol such as FastCGI with the application server. The article is talking about that communication.

They are not interchangeable for the browser-to-server communication, but they are for the server-to-application piece.

[assimpleaspossi]

Your last sentence is exactly what I said.

[opello]

You didn't though. You may have intended to?

The article points out that HTTP and FastCGI are both options for reverse proxies to communicate to the downstream server. I didn't find a reference to them being interchangeable outside of that context. If there is or was one please quote it.

[assimpleaspossi]

I was responding to the comment, not the article.

[opello]

> I agree with the article, FastCGI is better than HTTP for these things.

If this is what you mean to identify as claiming FastCGI and HTTP are generally interchangeable, and are rising to correct, I'll also offer that "agree with the article" and "these things" narrow the context to "for reverse proxy communication" and do not suggest the broader meaning you've interpreted.

[anon7000]

The article is really exclusively about the reverse proxy server to server use case, not client to server. The title even says it.

[assimpleaspossi]

I responded to the comment, not the article.