What does HTTP / 2 mean for reverse proxy?

Question

How does HTTP / 2 affect proxy server implementation? Especially, for example, when a client sends an HTTP / 2 request to a content server that only supports HTTP / 1.x, should the proxy convert the HTTP / 2 request to an HTTP / 1.x request before sending the client request to the server content? And after receiving a response from the content server, should the proxy server convert the response to HTTP / 2 format before sending it back to the client?

Answer 1

Yes, exactly as you say. The conversion from HTTP / 2 to HTTP / 1.1 should take place in one direction, and from HTTP / 1.1 to HTTP / 2 should take place in another case.

In practice, this means that although the HTTP / 2 protocol does not require a traditional text parser, a comprehensive HTTP / 2 server requires the HTTP / 1.1 parser, and not only for working with clients using only HTTP / 1.1 (scanners among them). ) but also for communicating with internal applications.

When using one of the most important application protocols is FastCGI. FastCGI also requires analysis of HTTP / 1.1 responses from the application and conversion to HTTP / 2 responses to the client.

Answer 2

As dsign discussed, your understanding is correct.

However, I thought it was worth noting that there are still huge advantages for HTTP / 2 on your border connection (i.e. your reverse proxy), since the problems solved by HTTP / 2 (primarily latency) are less significant due to typically shorter, usually high throughput from reverse proxy to content server.

For example, if you have a delay of 100 ms on the reverse proxy at the border and only 1 ms delay between the reverse proxy and the content server, then the fact that the content server says HTTP / 1.1 on the proxy server will probably not have a significant performance impact due to ultrafast 1 ms latency. So the end client (speaking HTTP / 2 with reverse proxy) still sees that the huge performance boasts HTTP / 1.1.