- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what's the expected way to detect a timeout error #626
Comments
Interesting. I haven't looked to see how timeouts are implemented on TcpStreams. Seems something conflicts with the optimizations openssl is doing? @sfackler |
It's a bug in SslStream's error handling. I will push a fix. |
This should fix it: sfackler/rust-openssl@69cbd14 Can you run the test against that and see if it resolves the issue? |
I'm not sure I can run that down stream. I hit this build error
this may be related to that? |
scratch that. I just needed to turn off hypers 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();
}
I suspect because I just opted out of hyper's default features in my build |
@softprops yep, if you turn off the |
I can't seem to the right combination of cargo config options make this happen. Can you provide an example? |
According to http://doc.crates.io/config.html
You can put it anywhere, and adjust the path. On Sat, Aug 8, 2015, 7:33 PM doug tangren notifications@github.com wrote:
|
okay. worked it out by cloning rust-openssl next to my project then creating a
now the errors are without https
and with https
@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 |
For what it's worth 35 seems to be mapped to 2 errors in libc. In rusts suggestions? |
@softprops according to http://linux.die.net/man/7/socket a timed out read will report the error |
I don't yet know what the best solution is. It may be worth discussion in internals about whether |
I tried asking in the original RFC: rust-lang/rfcs#1047 (comment) |
Cool thanks |
I picked |
@sfackler certainly not an expert in openssl's source, but my browsing found this: https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L2391 I couldn't find a check for the os error, so it could be completely ignored? Either way, it'd be nice if the returned error was the same as that from a |
Ok, try now. |
@sfackler I tried my little test app with your latest commit and now get a consistent error for both https and http requests in hyper.
I would prefer a |
The |
To make it consistent, I'd be fine with hyper matching WouldBlock and On Mon, Aug 10, 2015, 8:08 PM Steven Fackler notifications@github.com
|
That would probably seem weird to linux users. |
Is the something that could be stablized in the feature flagged socket timeouts in rusts std lib? |
@softprops is what something that could be stabilized? |
The error to expect when setting read write timeouts. I'm really excited to see this implemented but I'm finding little in the way of docs for how to handle timeout errors |
@softprops after lots of reading man pages and stack overflow questions, it seems the standard is this:
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. |
Ok. I know its common in some rustdocs to have a |
It seems we can't universally trust ErrorKind::WouldBlock to be returned when our short-timeout-workaround ends in the tcp response because only unix-like systems will return that. On Windows the io::Error raised will actually be ErrorKind::TimedOut, which actually makes sense, so `¯\_(ツ)_/¯` Props to @seanmonstar for all his "lots of reading man pages and stack overflow questions" that he mentioned in this comment hyperium/hyper#626 (comment) You don't know me, man, but may all of your wishes come true during your tenure upon this earth, because I could've pulled out a hell of a lot more hairs than I did if it wasn't for that comment 😅
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
andErrorKind.WouldBlock
in its tests for timeout failures. When I took hypers support for a spinerrors with
errors with
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.
The text was updated successfully, but these errors were encountered: