Clarification about reverse proxies and WebTransport

[FZambia]

Hello, could you please help me to find the answer to the question I was thinking about for quite a long time and can not come to something reasonable.

In production environments backend services which provide business logic often work behind reverse proxies. For extra security and load balancing at least. For example, let's consider Nginx as one of the most popular options.

Nginx now can terminate HTTP/3 traffic, but what it does then is proxying requests to the upstream using HTTP/1.1. When we talk about WebSocket protocol – it's OK also, Nginx can handle wss requests, terminate TLS, proxy Upgrade request, then act as a proxy for WebSocket frames.

Nginx is able to terminate HTTP/3, may transform HTTP/3 to HTTP/1 for simple request-response scenario. But how about WebTransport? Does this mean that the only way for Nginx is to proxy raw HTTP/3 traffic (secured with another TLS certs?) to the backend so that backend (written in NodeJS, Go, Python, etc.) could leverage WebTransport connections?

I also have not found any information about this for Haproxy - which also can terminate HTTP/3 but regarding long-lived streams (Webtransport) - it seems that the proxying is not possible.

Should all the existing reverse proxies be updated for WebTransport? It seems I am missing something fundamental here, because I can't put the puzzle together in my head - I can't imagine a situation when infrastructures will decide to skip using reverse proxies. At the same time most of users will terminate HTTP/3 on reverse proxy level I suppose and adding WebTransport support to such a system seems not clear.

[LPardue]

This is more a question for the WenTransport IETF group.

In short though, yes reverse proxies that want to support WebTransport will need to implement it, and implement appropriate transforms. The simplest approach is to implement support for WebTransport over HTTP/2 or HTTP/3 when speaking to the origin.

[FZambia]

@LPardue thanks for your answer. I actually missed a spec about WebTransport over HTTP/2 - thanks for mentioning. In general I am more confident in the understanding how it may work now. Probably recommendations from spec authors for reverse proxy authors could help to start movement in that direction?

Could you also clarify one other thing - I remember in drafts about WebTransport over HTTP/3 TLS was required, did this change with WebTransport over HTTP/2? I am thinking in a context when reverse proxy could terminate TLS traffic – but proxy streams to the upstream without TLS.

[LPardue]

@LPardue thanks for your answer. I actually missed a spec about WebTransport over HTTP/2 - thanks for mentioning. In general I am more confident in the understanding how it may work now. Probably recommendations from spec authors for reverse proxy authors could help to start movement in that direction?

Recommendations like that don't really work. The specifation's duty is to describe the protocol, the ecosystem decides uptake based on technical and non-technical matters. Designing a protocol with compelling features for use cases is the best way to encourage people to implement it, and that is clear here.

Could you also clarify one other thing - I remember in drafts about WebTransport over HTTP/3 TLS was required, did this change with WebTransport over HTTP/2? I am thinking in a context when reverse proxy could terminate TLS traffic – but proxy streams to the upstream without TLS.

HTTP/3 uses QUIC, which is always secure. Clear text HTTP/2 was not implemented widely and is basically a dead end. Since the WebTransport protocol requires either of these I don't Hinksey you'll see any standard propose clear text WebTransport. An interface between a load balancer and its backend is free to use whatever it likes as a private arrangement, but then it needs to do the work to figure out what that looks like.

[FZambia]

Many thanks for responses! Will be monitoring the ecosystem as time goes, nothing to add from my side at this point I suppose.