-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
requests treats urllib3's SSL handshake timeout as ReadTimeout #4590
Comments
Can you share more details about what makes you think there was a handshake error or other TLS issue that happened here? |
@gahancorpcfo I replaced original host with |
Hey @metheoryt, you're right that this does seem to be a misclassification of this particular timeout. If you look at the stacktrace though, you can see this is being done in urllib3, not Requests.
We only know what urllib3 is sending to us, so I don't know if we're easily able to do anything here. I'd recommend raising an issue with the urllib3 project and seeing if this can get clearer handling there. |
@metheoryt so the fact that a we timed out while in an SSL call doesn't inherently mean this is a SSL error that's being hidden. Let's look closely:
What this says is that while we were in the process of the handshake, we waited for 5 seconds while waiting for the server to write bytes. We'd already connected to the server (even if we hadn't established a TLS connection). In short, I personally do not see anything wrong here. It may not match what you expect, but it is absolutely correct. |
@sigmavirus24 yes, you're right in some ways, but I think this particular case should be treaten as connect timeout, cause
There's a significant difference between read timeout, when we don't know, does the server begins process of our request or not, and SSL stuff timeout, when we confident in fact that our request hasn't been processed at all. I think there's should be a distinction. |
@metheoryt I don't believe there's a way for urllib3 or requests to produce that distinction. I could be wrong, but I think that any solution would need to take place in the Python standard library since you can see the last portions of that trace are in
|
@sigmavirus24 we're using sentry as exception collector with our app, but I cannot share the original issue because our sentry instance is local. But I can explain stacktrace with screenshots below: how the low-level timeout exception is appearedwhere it is being handledhow it looks and where it turns to ReadTimeoutError |
Now I see clearly, @nateprewitt, you're right, I've posted an issue urllib3/urllib3#1366 with reference to this one |
@metheoryt you've only confirmed exactly what I've been saying. The exception is a |
@sigmavirus24 neither SSLError, nor ReadTimeout, I guess. It should be a ConnectionError, since it represents an error, produced while connecting to remote host, and subject request is safe to retry. |
@metheoryt let's review the sequence of events:
|
@sigmavirus24 I'm sorry if I misled you with I think of this situation as of borderline case between connection timeout and read timeout. Intuition acts as a background for the left part, while technical nature is a background for the right part. Indeed, TLS negotiation is a part of connection procedure. At this stage no business data is sent (even headers). There is no logical reason to treat this case as Another argument for |
I am seeing this issue as well. If you use a different timeout value for connect timeout and read timeout. For instance if you pass in (10, 1000), you will see a read timeout after 10 seconds even though the connect timeout is 10 seconds. Observed in requests 2.19.1 |
I confirm this behavior with 1.26.7 also when using urllib3 via requests. Passing two different timeouts makes it visible. If the connect timeout is large enough for the TCP connection to be established, but short enough for the TLS handshaking to fail, you get a It's all about the semantic we and urllib3 want to associate to the meaning of "connection". The TCP or the TLS ?? In any case, |
Expected Result
When connecting to a remote machine via SSL/TLS, and SSL handshake timeout happens, I expect to have
SSLError
orConnectionError
exception.Actual Result
requests
raisesReadTimeout
Reproduction Steps
I don't know how to reproduce this, but I have a real stacktrace (most recent call first):
System Information
The text was updated successfully, but these errors were encountered: