3 ms·

Can HTTP/3 be enabled in nginx now? Should it be? Is it a simple config change? I assume that would take care of serving static assets, but would reverse-proxie

by SiVal 6y ago

Can HTTP/3 be enabled in nginx now? Should it be? Is it a simple config change? I assume that would take care of serving static assets, but would reverse-proxied apps behind nginx also need to be upgraded to HTTP/3?

mjoras 6y ago
There are several efforts to implement QUIC and HTTP/3 in nginx. Cloudflare has it deployed in production with quiche[1], and Nginx themselves are developing one[2]. Applications sitting behind a proxy wouldn't need to be updated. The core protocol semantics of HTTP are relatively unchanged between HTTP/1.1, HTTP/2, and HTTP/3. [1] https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche [2] https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/ https://www.nginx.com/blog/introducing-technology-preview-ng...
nbm 6y ago
Pretty much any HTTP proxy supports talking a set of negotiated protocol versions/features with the client, and a potentially different set of protocol versions/features with the server behind it. The high-level flow is pretty much: 1) Set up client connection/negotiate stuff (TLS, alpn, NPN, blah blah) 2) Process requests from that client connection 2.1) Decode request from client connection 2.2) Manipulate request (add/remove headers, ...) 2.3) Send request to server 2.3.1) If necessary, create a new connection to server (TLS, alpn, NPN, ...) 2.3.2) Encode request to server connection 2.4) Decode response from server connection 2.5) Manipulate response (add/remove headers, ...) 2.6) Encode response to client connection You can talk totally different protocols from Internet-side client to the proxy, and from the proxy to the server - and multiple layers of proxies in between if you like. From an app point of view, there's essentially no difference. If you want to for some reason, you can use various headers to do attempt to indicate to the client to upgrade/downgrade to particular protocols, but most apps won't care about that.

by SiVal 6y ago

mjoras 6y ago

There are several efforts to implement QUIC and HTTP/3 in nginx. Cloudflare has it deployed in production with quiche[1], and Nginx themselves are developing one[2]. Applications sitting behind a proxy wouldn't need to be updated. The core protocol semantics of HTTP are relatively unchanged between HTTP/1.1, HTTP/2, and HTTP/3. [1] https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche [2] https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/ https://www.nginx.com/blog/introducing-technology-preview-ng...

nbm 6y ago

Pretty much any HTTP proxy supports talking a set of negotiated protocol versions/features with the client, and a potentially different set of protocol versions/features with the server behind it. The high-level flow is pretty much: 1) Set up client connection/negotiate stuff (TLS, alpn, NPN, blah blah) 2) Process requests from that client connection 2.1) Decode request from client connection 2.2) Manipulate request (add/remove headers, ...) 2.3) Send request to server 2.3.1) If necessary, create a new connection to server (TLS, alpn, NPN, ...) 2.3.2) Encode request to server connection 2.4) Decode response from server connection 2.5) Manipulate response (add/remove headers, ...) 2.6) Encode response to client connection You can talk totally different protocols from Internet-side client to the proxy, and from the proxy to the server - and multiple layers of proxies in between if you like. From an app point of view, there's essentially no difference. If you want to for some reason, you can use various headers to do attempt to indicate to the client to upgrade/downgrade to particular protocols, but most apps won't care about that.