Make examples/simple.rs compatible with hyper v1
#1
Conversation
| hyper-trust-dns = { version = "0.4.2", features = [ | ||
| "rustls-http2", | ||
| "dnssec-ring", | ||
| "dns-over-https-rustls", | ||
| "rustls-webpki" | ||
| ] } |
There was a problem hiding this comment.
Motivation: hyper-trust-dns was rebranded to hyper-hickory and no longer has a HttpsConnector, so using hyper-rustls instead.
| .https_or_http() | ||
| .enable_http1() |
There was a problem hiding this comment.
Only enabling http1 because http2 requires that the upstream server also supports http2, since we're not doing any http2-to-http1 translation at the moment.
| .build(); | ||
| ReverseProxy::new( | ||
| hyper_util::client::legacy::Builder::new(TokioExecutor::new()) | ||
| .pool_idle_timeout(Duration::from_secs(3)) |
There was a problem hiding this comment.
Motivation: The default idle timeout is 90 seconds, which is far too long for most services that you connect the reverse proxy to. My test service used 15 seconds, which means I started getting an error 15 seconds after I opened the reverse proxy.
Ideally the keep-alive header from the upstream server would be used automatically. But that can change per request, so I think it would require quite a lot of work to make this seamless. Open to ideas here.
There was a problem hiding this comment.
I started getting an error 15 seconds after I opened the reverse proxy.
Was this an error from hyper-reverse-proxy? If so I would say the solution would be to silence that error. If upstream has decided that an idle connection should get closed that's not really an error, that's business as usual (imo).
90 seconds does initially strike me as being too long for a default, but it's what go's builtin reverse proxy uses (via the DefaultTransport.IdleConnTimeout), and they've probably thought about it more than I have.
In any case the client would ideally honor the keep alive timeout provided by the server, but that's more a concern of the hyper_util::client than of ours.
There was a problem hiding this comment.
Sorry, I guess I wasn't very clear on what was happening here.
The error is:
LegacyHyperError(Error { kind: SendRequest, source: Some(hyper::Error(IncompleteMessage)) })
Because the connection between the proxy and the upstream service has been closed (in my case after 15 seconds), but the connection between the client and the proxy is still open. So on the next request the proxy will attempt to use a connection that is already closed, which results in the error.
Here's a GitHub thread discussing the issue: hyperium/hyper#2136
The TL;DR seems to be that it isn't always safe to automatically retry the request.
Anyway, I thought that it might be useful to include in the example, but perhaps it requires a comment explaining the problem.
There was a problem hiding this comment.
I see, maybe best to just include that link as a comment there for now 👍
| let host = req.headers().get("host").and_then(|v| v.to_str().ok()); | ||
| if host.is_some_and(|host| host.starts_with("service1.localhost")) { |
There was a problem hiding this comment.
The motivation for using the host header over the path is because the path is forwarded to the upstream server, and most servers will return a useless 404 for the path /target/first. Meanwhile, most servers will ignore what is in the host header, and most browsers let you use subdomains on localhost now, so http://service1.localhost should work for most cases out of the box. Using starts_with since the port number will be at the end!
There was a problem hiding this comment.
Thanks @stefansundin for the fixes to the example but also for the fixes to the README 🙏 🙇 I'll cherry-pick your commits now.
| .build(); | ||
| ReverseProxy::new( | ||
| hyper_util::client::legacy::Builder::new(TokioExecutor::new()) | ||
| .pool_idle_timeout(Duration::from_secs(3)) |
There was a problem hiding this comment.
I started getting an error 15 seconds after I opened the reverse proxy.
Was this an error from hyper-reverse-proxy? If so I would say the solution would be to silence that error. If upstream has decided that an idle connection should get closed that's not really an error, that's business as usual (imo).
90 seconds does initially strike me as being too long for a default, but it's what go's builtin reverse proxy uses (via the DefaultTransport.IdleConnTimeout), and they've probably thought about it more than I have.
In any case the client would ideally honor the keep alive timeout provided by the server, but that's more a concern of the hyper_util::client than of ours.
| use hyper_util::client::legacy::connect::HttpConnector; | ||
|
|
||
| type Connector = HttpsConnector<HttpConnector>; | ||
| type ResponseBody = UnsyncBoxBody<Bytes, std::io::Error>; | ||
|
|
||
| lazy_static::lazy_static! { |
There was a problem hiding this comment.
As long as you're here fixing up the example, I think it's no longer recommended to use lazy_static. From the lazy_static repo:
It is now possible to easily replicate this crate's functionality in Rust's standard library with std::sync::OnceLock.
So if anything it'd be better to use that.
There was a problem hiding this comment.
Good idea, I opened #2.
No description provided.