I'm maintaining a fork

[mediocregopher]

Hi all, I've begun a fork of this project at the following repo: https://code.betamike.com/micropelago/hyper-reverse-proxy/

I've extended upstream with the following changes:

• Fix for #53
• Upgraded to hyper v1
• Fixed some panics which can occur on a failed websocket upgrade

I'm not going to bother creating a new crates.io package for this or anything like that, if you'd like to use my fork you can do so by adding the following to your Cargo.toml:

[patch.crates-io]
hyper-reverse-proxy = { git = "https://code.betamike.com/micropelago/hyper-reverse-proxy.git", branch = "master" }

If you have any issues or patches with my fork you'd like me to be aware of please feel free to email me at the address in my GH profile.

Cheers!

[stefansundin]

Hello @mediocregopher,

Thank you for your work on this. I am wondering if you could update the example file to be compatible with the hyper upgrade?

I tried doing it myself but I have not been successful so far.

Looks like the tests are also failing, but that's less important.

Thank you!

[mediocregopher]

@stefansundin I'll add it to my todo list ;) in the meantime you can see how I'm using it here. It's pretty straightforward, you just need to use the hyper_util::client::legacy::connect::HttpConnector in the right way.

[stefansundin]

Hey @mediocregopher. I managed to figure it out. I forked your fork and created a branch with a fix.

Branch: https://github.com/stefansundin/hyper-reverse-proxy/tree/fix-example

I also created a PR just so that I could create inline comments with my motivation for some of the changes. Take a look here: https://github.com/stefansundin/hyper-reverse-proxy/pull/1

Please feel free to just add my GitHub repo as a git remote and cherry-pick the commit, or pull the branch with a merge commit. Whatever you want to do.

I would love to hear what you think about the idle timeout comment that I made here: https://github.com/stefansundin/hyper-reverse-proxy/pull/1/files#r1604319089. I was definitely confused until I figured that issue out. In an HTTP/1.1 world, ideally the library would automatically use the timeout value in the Keep-Alive header. But I don't think that would be easy to accomplish. But if it were then it would be one less thing to worry about.

Anyway, I hope this is useful to someone.