No, it's a great technology. For my purposes. Yours may be different.
I'm using the web for data retrieval. Text retrieval. I'm not interested in "interactive" web pages.
Every web user is entitled to their own opinion. I'll respect the opinions of those who like HTTP/2 so long as they respect the opinions of someone else who likes HTTP/1.1. From a privacy perspective HTTP/2 is flawed. But for me the more pertinent issue is that it's overkill. I'm using the HTTP/1.1 for data retrieval from the same host, where I want responses returned in the order they were requested, with HTTP headers. I'm not retrieving images, CSS and the like. I'm not looking at graphics. I'm retrieving text to be read in textmode. I have no need for "interactivity" and no need for multiplexing. For this purpose, HTTP/1.1 works beautifully. Nothing any HN commenter blurts out will change that fact. This reply was not even honest. "Servers don't support pipelining..." Where is this coming from.
I've been using HTTP/1.1 for over 20 years. I use it on a daily basis. As long as every httpd continues to support it, as they have for decades, I'll continue to use it.
Pipelining was designed to avert DoS by only opening one TCP connection. When RFC2616 came out, servers had problems with clients opening many TCP connections at once. This was considered poor netiquette. IETF wanted us to limit the number of connections to two.^1 Do so-called "modern" web browsers and other contemporary clients follow the old netiquette. As an HTTP/1.1 pipelining user, I only open a single connection. I'm still following the old netiquette.
What's funny about these replies trying to attack someone's use of HTTP/1.1 pipelining (which is quite strange if you asked me -- why would anyone care) is that the people making the replies have never tried to do what this person using HTTP/1.1 pipelling is doing. How could they claim it's "slow". Trust me, if it was typically slow I would not use it. Very rarely is it slow and even then it isn't any slower than making sequential TCP connections.
1.
Some excerpts
RFC 2616 HTTP/1.1 June 1999
8 Connections
8.1 Persistent Connections
8.1.1 Purpose
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet.
Persistent HTTP connections have a number of advantages:
- By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
- HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
- Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
- Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.
8.1.2.2 Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
8.1.4 Practical Considerations
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
No, it's a great technology. For my purposes. Yours may be different.
I'm using the web for data retrieval. Text retrieval. I'm not interested in "interactive" web pages.
Every web user is entitled to their own opinion. I'll respect the opinions of those who like HTTP/2 so long as they respect the opinions of someone else who likes HTTP/1.1. From a privacy perspective HTTP/2 is flawed. But for me the more pertinent issue is that it's overkill. I'm using the HTTP/1.1 for data retrieval from the same host, where I want responses returned in the order they were requested, with HTTP headers. I'm not retrieving images, CSS and the like. I'm not looking at graphics. I'm retrieving text to be read in textmode. I have no need for "interactivity" and no need for multiplexing. For this purpose, HTTP/1.1 works beautifully. Nothing any HN commenter blurts out will change that fact. This reply was not even honest. "Servers don't support pipelining..." Where is this coming from.
I've been using HTTP/1.1 for over 20 years. I use it on a daily basis. As long as every httpd continues to support it, as they have for decades, I'll continue to use it.
Pipelining was designed to avert DoS by only opening one TCP connection. When RFC2616 came out, servers had problems with clients opening many TCP connections at once. This was considered poor netiquette. IETF wanted us to limit the number of connections to two.^1 Do so-called "modern" web browsers and other contemporary clients follow the old netiquette. As an HTTP/1.1 pipelining user, I only open a single connection. I'm still following the old netiquette.
What's funny about these replies trying to attack someone's use of HTTP/1.1 pipelining (which is quite strange if you asked me -- why would anyone care) is that the people making the replies have never tried to do what this person using HTTP/1.1 pipelling is doing. How could they claim it's "slow". Trust me, if it was typically slow I would not use it. Very rarely is it slow and even then it isn't any slower than making sequential TCP connections.
1.
Some excerpts
RFC 2616 HTTP/1.1 June 1999
8 Connections
8.1 Persistent Connections
8.1.1 Purpose
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet.
Persistent HTTP connections have a number of advantages:
- By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
- HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
- Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
- Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.
8.1.2.2 Pipelining
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
8.1.4 Practical Considerations
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.