4 ms·
I really disliked the following part: A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the connection header.
by ge0rg 13y ago
I really disliked the following part: A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the connection header. [..] Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections. (Section 3.4)
That means, whenever you open a new TCP connection to a http2 server, you must start with HTTP/1.1 and perform the Upgrade negotiation anew.
Making the spec require HTTP2 support on all servers of a cluster if at least one server supports it would have been much better, performance-wise. The only reason I see why they kept it is transparent proxies (if your browser is using an explicit proxy, it should be able to figure out if the proxy supports HTTP2).
- peterwwillis 13y agoBrowsers already send HTTP/1.1 by default, which would be rejected by HTTP/1.0 servers. HTTP/2.0 would be rejected by HTTP/1.1 servers and the browser could retry, or it can try for the Upgrade. Either way, with time, we can change the browser to behave differently based on the number of servers supporting that protocol, the same as with HTTP/1.1.
- ge0rg 13y agoYes, but storing "supports HTTP2" for a given server for a given time after connecting to that server and negotiating the upgrade would also do the job. One of the problems with HTTP 1.x is that it is stateless - every time you want something from a server, you treat it as if it is the first time you talk to it. I understand this is by design, but as a consequence we are transmitting all the same headers to the server all the time... which can be mitigated with HTTP2, except that we still need to do that (send all headers) and the HTTP2 upgrade, every time we open a new TCP socket to that server.