Support `h2c` (HTTP/2) for listeners

[schildbach]

When a listener's type is http and tls is false, please also support h2c protocol. Currently, only HTTP 1.1 is supported in this case. When trying to connect via HTTP/2, there are errors in the log and the request is ignored.

Client:

# docker compose exec synapse curl --http2-prior-knowledge http://localhost:8008/
curl: (16) Remote peer returned unexpected data while we expected SETTINGS frame.  Perhaps, peer does not support HTTP/2 properly.

Server log:

synapse.http.site - 422 - INFO - sentinel - Connection from IPv6Address(type='TCP', host='::1', port=50648, flowInfo=0, scopeID=0) lost before request headers were read

HTTP/2 is useful for running behind reverse proxies when they commonly terminate the SSL, so the connection from reverse proxy to Synapse is not transport encrypted.

[reivilibre]

Can you explain your motivation or problem that means you need to use HTTP/2 here?

Most common reverse proxies are capable of serving HTTP/2 but using HTTP/1.1 on the backend. This is usually fine because the client still gets the multiplexing benefits whereas the backend doesn't really benefit from that anyway, as the connection between reverse proxy and backend is usually of low latency and high quality.

In more practical terms, it would be tricky for Synapse to support HTTP/2 right now; see for example that Twisted does not have mature support for it yet: https://docs.twisted.org/en/stable/api/twisted.web._http2.html

[schildbach]

First of all, if your HTTP library doesn't support HTTP/2 right now then I understand your hesitation. I was assuming Synapse supports HTTP/2 anyway in the form of h2 (HTTPS) and enabling h2c would just be a "flip of a switch". Even if that's not the case, I would suggest putting h2c on the list of "future ideas".

HTTP/2 has many advantages, e.g. request multiplexing, priorization and server push. Some protocols already mandate it afaik, e.g. DoH and gRPC, so it's unlikely reverse proxies would not support it. The two I've used, nginx and Traefik, do support HTTP/2 also on the backend. They just sometimes don't negotiate upgrades from HTTP/1.1 to 2 and thus require so-called "prior knowledge" (of HTTP/2 being available).

My main motivation is reducing code paths. Having to rely on the ancient HTTP/1.1 code path is a liability. Also the conversion between HTTP/2 and HTTP/1.1 places additional burden on the reverse proxies and adds failure modes.