91–100 of 107 posts
What I'd like to see is someone creating local caching proxy for modern https infested world. I'm fed up with downloading same packages 100 times.
Earlier quoted context omitted.
>> 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…
I didn't quote anything from the article. I was responding to the comment, not the article.
Earlier quoted context omitted.
The HTTP semantics are useful for anyone developing a web app but the wire protocol of HTTP itself is awful. Multiplexing didn’t arrive until HTTP 2.0 for example. So using HTTP for communication between a reverse proxy and a backend is very wasteful. There are security issues, such as when different parsers could even disagree on where the boundaries of a request ends. Google for example has long wrapped HTTP into t…
> Multiplexing didn’t arrive until HTTP 2.0 for example. So using HTTP for communication between a reverse proxy and a backend is very wasteful. HTTP 2.0 multiplexing is tcp in tcp, it's asking for trouble. Just open more connections and let tcp be your multiplex. Depending on your connection rate, you can't really do 64k connections per frontend ip to each service ip:port, but if your rate isn't too high, 20-30k is…
It’s not. It doesn’t literally run another TCP congestion control algorithm inside a TCP tunnel. However I do agree that the implementation of multiplexing in HTTP/2.0 isn’t the best; it could have been better.
Earlier quoted context omitted.
> It launches more server tasks when the load goes up, shuts them down when the load decreases In my experience, this isn't a good feature. It sounds nice, but it can often mean everything runs fine while your load is low, but when your load gets high, you spawn more workers and run out of memory. It's much better to have a static number of workers in my experience. Crash recovery is handy, if needed though.
It's useful if you have multiple FCGI programs that handle different kinds of requests. Depending on what's being requested, programs start up and shut down.
> That said, using a vintage technology has some downsides. It was never updated to support WebSockets With widespread browser support for WHATWG streams, it's pretty easy to implement your own WebSockets over long-lived HTTP requests. Basically you just send a byte stream and prepend each message with a header, which can just be a size in many cases. Advantages over WebSockets: * No special path in your server layer…
Please be aware that there is a web standard for this since quite some time. See server-sent events and the EventSource interface: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource
Earlier quoted context omitted.
I didn't quote anything from the article. I was responding to the comment, not the article.
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.
Earlier quoted context omitted.
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.
And I was saying his comment is wrong. Sometimes HN can be just so reddit-like.
"These things" being the communication between a proxy and the backend.
Earlier quoted context omitted.
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.
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.