4 ms·

Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported

Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.

eeeeeeeeeeeee 8y ago
I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.
- Kalium 8y ago
  You're right! Technology should under no circumstances by adopted blindly. Costs and opportunities should always be weighed carefully. Given that TLS is mention in-line as also breaking this point, I think it perhaps possible that some readers might be of the opinion that the decision-making process you call for has already been conducted. Since TLS breaks the standard of "it is human-eyeball-friendly with telnet/netcat", HTTP/2 is little different in the minds of many. Your caution is right and apt. The history of computing is littered with technologies that were unready, unsuitable, or otherwise not fit for purpose when adopted.
acdha 8y ago
> HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc. > It also can't be supported by a lot of old software without some additional layer of indirection This part is true but it's also the classic legacy computing problem: old software which cannot be upgraded will increasingly have security and compatibility issues which favor putting it behind a proxy anyway. This should factor into the cost of choosing not to maintain those systems rather holding back the future.
- skywhopper 8y ago
  How is HTTP/1.1 holding anything back?
  - acdha 8y ago
    HTTP 1 has a fixed feature set and a lot of warts. Nobody is working on HTTP 1.2, etc. so the only way anything is going to get better will be in the HTTP/2 series of development. At some point we need to ask whether skimping on maintenance is actually better than getting those improvements.
protonfish 8y ago
Hopefully we all agree that maintainability is the most important quality of code (after successfully performing the feature that it was meant to implement.) Writing readable, modular code is key to getting the most out of developer time and preventing bugs. With that in mind HTTP/2 is a huge step backwards. And for what? Slightly faster speeds? This is a non-problem. When I see a slow site and view the network performance to discover why (using tools that would most likely not work under HTTP/2) here is what I inevitably see: * Massive video and JavaScript for ads * JavaScript tracking code * Massive HTTP headers with unnecessary cookies * Unnecessary, bloated JavaScript libraries * Unnecessary, bloated CSS files * Gratuitous unoptimized images * No attempt at optimizing HTTP caching settings * No attempt at HTTP compression (gzip) These will still be the main bottlenecks with HTTP/2. HTTP/2 solves no problem and makes network application development more difficult by making the network calls opaque and gratuitously complex.

eeeeeeeeeeeee 8y ago

I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.

Kalium 8y ago
You're right! Technology should under no circumstances by adopted blindly. Costs and opportunities should always be weighed carefully. Given that TLS is mention in-line as also breaking this point, I think it perhaps possible that some readers might be of the opinion that the decision-making process you call for has already been conducted. Since TLS breaks the standard of "it is human-eyeball-friendly with telnet/netcat", HTTP/2 is little different in the minds of many. Your caution is right and apt. The history of computing is littered with technologies that were unready, unsuitable, or otherwise not fit for purpose when adopted.

acdha 8y ago

> HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc. > It also can't be supported by a lot of old software without some additional layer of indirection This part is true but it's also the classic legacy computing problem: old software which cannot be upgraded will increasingly have security and compatibility issues which favor putting it behind a proxy anyway. This should factor into the cost of choosing not to maintain those systems rather holding back the future.

skywhopper 8y ago
How is HTTP/1.1 holding anything back?
- acdha 8y ago
  HTTP 1 has a fixed feature set and a lot of warts. Nobody is working on HTTP 1.2, etc. so the only way anything is going to get better will be in the HTTP/2 series of development. At some point we need to ask whether skimping on maintenance is actually better than getting those improvements.

protonfish 8y ago

Hopefully we all agree that maintainability is the most important quality of code (after successfully performing the feature that it was meant to implement.) Writing readable, modular code is key to getting the most out of developer time and preventing bugs. With that in mind HTTP/2 is a huge step backwards. And for what? Slightly faster speeds? This is a non-problem. When I see a slow site and view the network performance to discover why (using tools that would most likely not work under HTTP/2) here is what I inevitably see: * Massive video and JavaScript for ads * JavaScript tracking code * Massive HTTP headers with unnecessary cookies * Unnecessary, bloated JavaScript libraries * Unnecessary, bloated CSS files * Gratuitous unoptimized images * No attempt at optimizing HTTP caching settings * No attempt at HTTP compression (gzip) These will still be the main bottlenecks with HTTP/2. HTTP/2 solves no problem and makes network application development more difficult by making the network calls opaque and gratuitously complex.