open design question: some mechanism for handling upgrades

[jbr]

this is also an async-h1 client issue, but ideally would be exposed at both the surf and http-client levels as well — users may want to upgrade a request made with http-client to a websocket. this is especially relevant in a reverse-proxy scenario, but there may be other use cases as well

[Fishrock123]

I have pretty much zero thoughts on this, so, any suggestion is welcome.

[jbr]

I'm also not at all sure — I think this probably would require using the channel-based upgrade approach that tide uses for requests, but we'd need to look into what each of the backends supports for upgrade mechanism. If they all give us access to the TcpStream (or tls-wrapped TcpStream), this is more approachable. It's also pretty reasonable to just say that if you want to have this level of granularity in a reverse proxy, you should directly use async-h1, at which point it's as easy as taking a clone of the transport beforehand

[Fishrock123]

When using websockets for example, wouldn't you have tungstenite connect directly? What would be the advantage here?

[jbr]

When building a reverse proxy, you still need to handle connecting the websocket request to the upstream, but you don't know ahead of time which requests will be upgrades. You receive some request headers from the downstream, you send them to the upstream, it sends back response headers signifying a successful upgrade negotiation, you forward them to the downstream, and then you plug together the two raw transports for them to talk whatever other protocol (eg websockets). I've got this working in my other project using a purpose-built client (and https://github.com/jbr/full-duplex-async-copy, which I extracted for this exact use case), but thought I'd leave a note here since there's been some discussion of building reverse proxies on tide