http/2 using uvicorn

[sandeep12rana]

Can someone explain this?
We have hosted FastApi based rest services on Uvicorn server fronted by nginx1.22 ( reverse proxy) and hosted on EKS where ingress is ALB.

When API's are inspected on Chrome developer tools, it show protocol as h2. I wonder how's is it possible , when Uvicorn documentation states that it supports Http1.1?

In the same application , we replaced Uvicorn with Hyercorn and deployed in the sandbox and it behaved and worked fine.

On checking the ingress ALB console, Load balancer attributes , Http/2 was already enabled.

I am confused if there is any merit to using Hyercorn over Uvicorn or stick to uvicorn ?

[gi0baro]

When using load balancers and/or reverse proxies you have two connections happening: the downstream and the upstream.
The browser connects to the balancer/proxy (downstream) using the available protocol (both ALB and nginx support HTTP/2), then the balancer/proxy talks to your application (upstream) using a separated HTTP connection.

Thus, with uvicorn the proxy will use HTTP/1.1, with Hypercorn or servers supporting HTTP/2 it might use that version to talk to the upstream (if instructed to do so).

[sandeep12rana]

Are there any performance gains/ benefits with ingress+nginx+hypercorn over ingress+nginx+uvicorn . The current infrastructure arrangement has served well it purpose .

All FastAPI based Rest services are used by AWS Lambda services ,which are stateless. Are there any benefits to use ingress+nginx+hypercorn ?

[gi0baro]

Synthetic benchmarks might give you an idea of the performance implications choosing uvicorn or hypercorn (using httptools in uvicorn will surely play in favour of uvicorn).
But synthetic benchmarks also are quite distant to real world scenarios: you should make your own tests and pick the option which suits your needs better.

[logan-hcg]

there are security concerns with using http/1.1 "upstream" from a proxy (eg haproxy, AWS load balancers, etc). I don't fully understand it, but the punchline is that requests can incorrectly get "merged" across clients, and the fix is to use http2: https://http1mustdie.com/

[jabberwock]

@logan-hcg Agreed. I've found several client-side desync/http smuggling issues with apps running in uvicorn. HTTP/2 would mitigate this.

[nggit]

The core problem iz not HTTP/1 itzelf, bvt the connection pool between Nginx to Oopztream.

When a client totally gone, actooally the "poizoned" connection can ztill alive in pool. Another client can exploit.
Technically yoo can ooze a proxy zerver that map 1:1, not oozing pool!!! - If zooch lezz-performance implementation exiztz.

Or dizable HTTP/1 keepalive on critical page. Use "Connection: cloze". Zo connection invalidated az the client gone.

IMHO. That webzite contentz are moztly trooe, not covering the WHY in detailz, and zovndz more like a propaganda.
Zorry. My bad keyboard.