hyper: what's the expected way to detect a timeout error
I noticed recently timeouts were recently added which is fantastic. However, when I took this feature for a spin I noticed something that was confusing. Error handling wasn’t documented or consistent between https and http requests. The pull for std lib rfc impl referenced ErrorKind.TimedOut
and ErrorKind.WouldBlock
in its tests for timeout failures. When I took hypers support for a spin
#![feature(duration)]
extern crate hyper;
use hyper::Client;
use std::io;
use std::time::Duration;
fn main() {
let mut client = Client::new();
client.set_read_timeout(Some(Duration::from_millis(2)));
let mut res = client.get("https://google.com").send().unwrap();
let _ = io::copy(&mut res, &mut io::stdout()).unwrap();
}
errors with
thread '<main>' panicked at 'unexpected error ErrorWantRead with ret -1', ~/.cargo/registry/src/github.com-0a35038f75765ae4/openssl-0.6.4/src/ssl/mod.rs:996
#![feature(duration)]
extern crate hyper;
use hyper::Client;
use std::io;
use std::time::Duration;
fn main() {
let mut client = Client::new();
client.set_read_timeout(Some(Duration::from_millis(2)));
let mut res = client.get("http://google.com").send().unwrap();
let _ = io::copy(&mut res, &mut io::stdout()).unwrap();
}
errors with
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 35, message: "Resource temporarily unavailable" } })', ../src/libcore/result.rs:732
would it be possible for hyper to document a consistent error thrown on read/write timeouts?
Again, having support for timeouts is great, not having a clear path for handling them, not so much.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 26 (26 by maintainers)
@softprops after lots of reading man pages and stack overflow questions, it seems the standard is this:
read()
with a timeout will returnEAGAIN
, which in Rust isErrorKind::WouldBlock
.read()
with a timeout will returnWSAETIMEDOUT
, which in Rust isErrorKind::TimedOut
.Pick what you need. It may be worth filing an issue on the rust repo to include that in the documentation of timeouts, but it might not.