A naive proxy example could be a good idea! Though, there isn't currently a way to get the on_upgrade in warp to allow for tunneling.

Looking at this it looks like this is about a Request/Response combination that results in a usable Socket afterwards? I must say the documentation isn't exactly verbose.

I'm looking to do Cut-through switching. That is I want to validate and alter Request Headers and then hand off the Body to another HTTPD without storing the body(could be several GB of file upload). I likewise want to do the same with the Response, for file downloads.

The whole story. I recently wanted to share a saved game file but I was unable to locate a file sharing service that I was happy with. I've obtained a VPS from Google, but it has limited storage. I plan to use FreeNet as my file storage backend. What I'm looking to do is pass through filtered access to an instance of FreeNet.

Can Warp do anything like this?

Edit: Similar to #175

The code for warp::filters::ws could in principle be adapted into a HTTP CONNECT proxy (like the linked hyper example), but it relies on the body filter (which is private) to get access to the underlying hyper structs. So I think implementing that example in warp is actually impossible right now without changes to the library.

@seanmonstar warp seems to be careful about keeping the raw Body hidden, so I assume you want to keep it that way (so exposing the body filter wouldn't be an option). What would you think about an upgrade filter that exposes a hyper::upgrade::Upgraded? The ws filter should be able to reuse it, and the downcast function on that can get you all the way back to a raw tokio TcpStream for @cheako 's use-case (as well as my own).