what's the expected way to detect a timeout error

[softprops]

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.

[seanmonstar]

Interesting. I haven't looked to see how timeouts are implemented on TcpStreams. Seems something conflicts with the optimizations openssl is doing? @sfackler

[sfackler]

It's a bug in SslStream's error handling. I will push a fix.

[sfackler]

This should fix it: sfackler/rust-openssl@69cbd14

Can you run the test against that and see if it resolves the issue?

[softprops]

I'm not sure I can run that down stream. I hit this build error

native library `openssl` is being linked to by more than one package, and can only be linked to by one package

  openssl-sys v0.6.4 (https://github.com/sfackler/rust-openssl#69cbd145)
  openssl-sys v0.6.4

this may be related to that?

[softprops]

scratch that. I just needed to turn off hypers default-features flag to force my local dep to take priority

Now when I run the same code for an https url I get a different error

#![feature(duration)]

extern crate hyper;

use hyper::Client;
use std::io;

use std::time::Duration;

fn main() {
  println!("test");
  let mut client = Client::new();
  client.set_read_timeout(Some(Duration::from_millis(10)));
  let mut res = client.get("https://google.com").send().unwrap();
  let _ = io::copy(&mut res, &mut io::stdout()).unwrap();
}

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Custom(Custom { kind: InvalidInput, error: StringError("Invalid scheme for Http") }) })', ../src/libcore/result.rs:732

I suspect because I just opted out of hyper's default features in my build

[seanmonstar]

@softprops yep, if you turn off the ssl feature, then the DefaultConnector is HttpConnector. I believe you can override the path of the openssl using .cargo/config.

[softprops]

I can't seem to the right combination of cargo config options make this happen. Can you provide an example?

[seanmonstar]

According to http://doc.crates.io/config.html

paths = ["../openssl"] in a .cargo file next to your Cargo.toml.

You can put it anywhere, and adjust the path.

On Sat, Aug 8, 2015, 7:33 PM doug tangren notifications@github.com wrote:

I can't seem to the right combination of cargo config options make this
happen. Can you provide an example?

—
Reply to this email directly or view it on GitHub
#626 (comment).

[softprops]

okay. worked it out by cloning rust-openssl next to my project then creating a .cargo/config file with

paths = ["/abs/path/to/rust-openssl"]

now the errors are without https

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

and with https

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Custom(Custom { kind: TimedOut, error: StringError("socket read timed out") }) })', ../src/libcore/result.rs:732

👍 @sfackler

@seanmonstar thoughts aligning the non ssl timeout request err with a similar err kind? Ideally something like io::ErrorKind::TimedOut would make it easier to handle these errors consistently

[softprops]

For what it's worth

35 seems to be mapped to 2 errors in libc. In rusts io module these seem to map to a ErrorKind::WouldBlock so I'm not sure if this mapping is actually a bug in rust itself. TimedOut errors are mapped here to the ETIMEDOUT const in libc. os code 60 ( shrugs ).

suggestions?

[seanmonstar]

@softprops according to http://linux.die.net/man/7/socket a timed out read will report the error EAGAIN/EWOULDBLOCK (they're the same constant, as you've noticed).

[seanmonstar]

I don't yet know what the best solution is. It may be worth discussion in internals about whether TcpStream should map WouldBlock to TimedOut iff the socket has a timeout set. Socket timeouts are still unstable, so these details may not have had enough testing.

[seanmonstar]

I tried asking in the original RFC: rust-lang/rfcs#1047 (comment)

[softprops]

Cool thanks