FastCGI has "parameters" and HTTP headers are special parameters starting with "HTTP_" (mimicking CGI's environment variables). All parameters not starting with "HTTP_" can be trusted because only the web server (= FastCGI client) can construct them.

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

Though I'd like to make another protocol known: Web Application Socket (WAS). I designed it 16 years ago at my dayjob because I thought FastCGI still wasn't good enough.

Instead of packing bulk data inside frames on the main socket, WAS has a control socket plus two pipes (raw request+response body). Both the WAS application and the web server can use splice() to operate on a pipe, for example. No framing needed. Also, requests are cancellable and the three file descriptors can always be recovered.

Over the years, we used WAS for many of our internal applications, and for our web hosting environment, I even wrote a PHP SAPI for WAS. Quite a large number of web sites operate with WAS internally.

It's all open source:

- library: https://github.com/CM4all/libwas - documentation: https://libwas.readthedocs.io/en/latest/ - non-blocking library: https://github.com/CM4all/libcommon/tree/master/src/was/asyn... - our web server: https://github.com/CM4all/beng-proxy - WebDAV: https://github.com/CM4all/davos - PHP fork with WAS SAPI: https://github.com/CM4all/php-src

>> FastCGI is better than HTTP for these things.

> 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. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not.

That might be just you. The article is littered with the qualifier "for reverse proxies", including in the title and two section headers, and "as the protocol between reverse proxies and backends" in the second paragraph. I don't know how it could be any more clear on this point.

The max_k comment you've quoted includes "for these things"; context clues suggest by "these things" he also means to limit his comment to the reverse proxy <-> backend leg.

The comment was made in response to the article. This whole discussion is in the context of the article. You choosing to ignore that doesn't mean everyone else has to let you.

His comment is _not_ wrong. He says "I agree with the article, FastCGI is better than HTTP for these things."

"These things" being the communication between a proxy and the backend.

Thanks, but I feel we're all just feeding this one troll. Don't bother replying anymore, it's pointless.

> I didn't quote anything from the article.

You referred to it: "just now I glanced at the article and it seems the author writes in a confusing way..."

> I was responding to the comment, not the article.

It sure looks like you were responding to both, and I addressed both. Also, you're going to have a hard time understanding HN comments if you don't read top-level comments as responses to the article, even if they don't start with "I agree with the article" as max_k's comment did.

> 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.

Your last sentence is exactly what I said.

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.

I was responding to the comment, not the article.

> 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.

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

> imply that HTTP and FastCGI are interchangeable and they are not.

But they are interchangeable!

FastCGI and HTTP/1.1 are indeed on the same level. Both are transport protocols for HTTP requests.

It would be technically possible to implement FastCGI as alternate transport protocols in browsers and web servers, just like HTTP/2 (SPDY) and HTTP/3 (QUIC) are alternate transport protocols for HTTP requests.

(This is not what the article and my comment are about, as others already pointed out.)

I feel like the author of an alternative protocol probably knows these things.

I think the author mentions HTTP because many people use it where they could be using FastCGI and just don’t.

Please note that it's called FastCGI, not FastHTTP.

Again, you’re pointing out things that are obvious to those involved and I’m not sure why.

Because, besides you, the rest of HN is oblivious to the obvious judging by the downvotes.

And yet I’ve seen in production the (ab)use of HTTP where fcgi would’ve been a much better fit.

Oh, there's another stgit user! ^5 Coming from darcs, I couldn't use git until stgit came along, and today, it's one of those few tools I can't imagine working without. Nothing else matches my way of code hacking. So often, I watch people making a big mess with git, and I always recommend stgit to them, so they can post proper and reviewable branches for merging. But in all these years, I could never convince anybody.

Yes, "it’s just the linter being noisy".

> Otherwise, the very first commit should be removing all the personally identifiable information and other telemetry sent back to Matt's personal website

This is one of the things I removed in our WordPress fork. I found it horrifying to learn that an open source software does such a user-hostile thing, and wondered why nobody but me objects.

Related: do only what is necessary. This works on so many levels and is my magic trick to make software faster.

It's a pity computers are so fast and have so much memory that people can get away with not caring about minimalism.

Me too! I've been using it for 20 or so years, and it's one of those pieces I didn't know it was still developed or what features were added, because the feature set from 20 years ago is still enough for me. IOW: maybe it doesn't need a maintainer at all.

I want to share a comment I wrote on the 2.1.0 release announcement in 2011: https://news.ycombinator.com/item?id=3309575

Why does the Android app require access to my location? I wouldn't expect open source apps to spy on me.

Back in the days, you had a UI toolkit, and everybody would use those native controls; they looked and felt the same in all application, and you had a central place where you could customize the look. Now every application/website has customized controls for everything; everything looks and works differently. (And don't even get me started with websites implementing their own scrollbars with JavaScript. Uh!)

Custom list control: do Home/End buttons work? How to select multiple items, does Shift-Cursorkeys work? Does Ctrl-Click work? Of course not.

Custom text control: does Ctrl-Left/Right for word jumping work? Does Ctrl-Up/Down for paragraph jumping work? Can I select everything with Ctrl-A or does it select the whole website? Can I select everything from cursor until the end with Ctrl-Shift-End work? Does Copy/Paste work at all? (I have never figured out why Copy/Paste in Teams simply doesn't work. Apparently I'm the only one with this problem.)

Custom dropdown control: does Alt-Down work? Can I scroll the list with the usual keys?

If (web) developers would just use standard controls, everything would work the same, and they wouldn't have to reimplement all the basic things from scratch (or not at all). Web devs could write forms that work without megabytes of JavaScript.

Hamburger menus. Those horrible things didn't need to exist even in old times with small monitors and 640x480 (or less) - but now they exist everywhere on my 32" 4K monitor for no reason.

Me too, agree with you and GP. And I can't keep wondering why this opinion is so unpopular. Today's UIs are bloated with unnecessary animations (which adds latency). But worse than animations is that UIs are horribly inconsistent; took me a while to figure out those toggles should be clicked, not dragged; or: what is even clickable, how do I scroll, ...? I could go on forever, and probably so can you.

Why do only old nerds complain about this, when today's UIs are so "easy" that every toddler can use the smartphone? Are we just living in the past, getting old; are we the problem, why is our opinion unpopular?

> why is our opinion unpopular?

I think other people do feel a vague sense of anxiety using modern software from not quite knowing what all the interaction patterns are. When you click that hamburger menu on the website, what will it do, exactly? But most people from outside the software world just blame themselves for “not being very good with computers”.

The problem is that it’s not fashionable any more amongst designers to use built in controls. Everyone wants to think of themselves like Apple, and build their own beautiful design language. Even if it’s just for their own website or app. And it sort of makes sense given modern apps end up needing to be built for the web, iphone, iPad, Android, and the desktop. It makes sense to tie all of those pieces of software together with a cohesive visual language and style.

UI has become the domain of marketing and branding.

I'm old now, and I won't dismiss that the new stuff is aesthetically nice. It's also not that hard to use. But I just don't like the visual polish more than I like the clarity and responsiveness of the old UI elements.

I just don't care if my computing experience is beautiful. I care if it's snappy, productive, and reliable.

> I just don't like the visual polish more than I like the clarity and responsiveness of the old UI elements.

Agree, that sums my opinion well.

And much software doesn't even look like they preferred eye candy over clarity; it rather looks like they forgot about clarity completely.

I mostly find the way the opinion presented in this thread by many people exhausting.

You're doing it there too: You're throwing every bad point of every bad UI you ever encountered into a bucket and throw all of that at this article by concluding "Animations in UI are terrible and just bloat everywhere". That's very close to a strawman.

I have worked and AB-tested in UIs for games and such dealing with just that and I would much rather say: Bad UIs are bad, yes. And animations don't help bad UI not being bad. But if you have a good, understandable UI, adding animations smartly - without impeding the user and in subtle fashion - on top of that UI... that can increase the overall aesthetics of the UI a lot and make the UI much more pleasing to use.

I agree with that; animations can be OK, but when I have a configuration setting, I usually disable them because input latency drives me crazy.

My post replied to "checkboxes vs UI toggles", and replying to that aspect was my main point. That's slightly off-topic, of course. It has to do with animations only because checkboxes wouldn't really benefit from animation, whereas toggles are an obscure visual representation for the same control, and adding animation is a feeble attempt to make it somewhat less obscure, even though it doesn't even try to address the main problem: what does toggle "left" and "right" really mean?

I believe checkbox not benefting from animation is a good thing: it's so clear and obvious that you don't need to animate it.

> what does toggle "left" and "right" really mean?

Nothing, because that's not the point of the article.

It's weird to me that this is such a big point here.

In an actual UI, you will have labels or indicators telling you what the toggle means and what the options are - "Safety door unlatched" vs "Control motors engaged". That's a toggle between two choices and having it a toggle like that would be safer than checkboxes.

Otherwise your checkbox without labels is equally bad UX because what does "on" and "off" mean for an unlabeled checkbox? I could give enough examples from work how vaguely labeled checkboxes like "remote authentication" are terrible UX.

> that's not the point of the article.

Of course not. The post you're replying to explicitly said the discussion was off-topic. That means it's not discussing the point of the article.

> In an actual UI, you will have labels or indicators telling you what the toggle means and what the options are

If it only were that way, we wouldn't complain. But it's not.

> checkbox without labels is equally bad UX

Of course, I agree. But nobody asked for that.

Your post ignores the things that were said and replies to things that were not said.

For toggling between mutually exclusive choices please use radio buttons. Checkboxes, and less obvious variants, are for enabling/disabling clearly labeled options that are not mutually exclusive.

That used to be Interaction Design 101 back in the olden days, ie. 1990s.