Python 3.3 requests issue #1289
Comments
|
Please reply with the following: |
|
Requests version 1.1.0. |
|
@t-8ch can explain this in detail but upgrading to 1.2.0 should fix all of your problems. |
|
Excellent! I'll test it out. Thank you for your quick response. :) |
|
If it doesn't fix it for you, feel free to re-open the issue or ask me to do it for you. |
|
I'm still having the same failure, no matter where I run it. |
|
Is the URL meant to be publicly accessible? On python3.3 the ssl module raises a Could it be, that your testsuite is somewhere checking the message of the |
|
I was checking for socket.error, however, this isn't the issue (I tested with and without it and it still causes the same failure.) Theoretically, according to PEP 3151, it shouldn't be an issue either, because socket.error is an alias for the new OSError. (right?) http://docs.python.org/dev/whatsnew/3.3.html Unfortunately this isn't a public API. :( Based on the error I'm seeing, I'm certain this has to be my code... :| Thank you so much for your kind help. You guys are really awesome. :) I hope to have this code open sourced before too long here, so I'll update this thread when that happens. Maybe we can get to the bottom of this... |
|
I'm hitting the same problem with Requests 1.2.3 running on Python3.3. |
|
@AvivLander Have you tried the solution proposed in #1418? |
|
@Lukasa Thanks for the suggested solution. Although, I'm not using SSL in my requests. |
|
Really? You're seeing this error without using SSL? I'm not entirely sure that's possible. Can you copy your traceback? |
|
@Lukasa, It very well could be an error with the script and not the library. The odd thing here is that the address in question is completely accessible. Here's a traceback: |
|
So the problem here is right at the end of the exception text: the original exception is |
|
So there's actually an error before: |
|
It should not be possible to hit that error. urllib3 has had a try..except block catching that exception since Requests v0.13.2. Try reinstalling Requests? |
|
The issue was related to urllib3 and AWS ELB. It was resolved when routing the request without the ELB. Hardly a desirable option... Regardless, thanks for your help @Lukasa . "First, ELB has internal "feature" of closing all incoming HTTP connections that do not get response within 60 seconds. I.e. if your client executes GET ... and waits for more then 60 seconds - ELB will close the connection. This timeout is currently unconfigurable through amazon API and even not advertised in Amazon docs. " |
|
@AvivLander Glad you managed to get to the bottom of this. |
|
I still get the TypeError: getresponse() got an unexpected keyword argument 'buffering' for some reason, even though I have Requests 1.2.3 and Python 3.3.1 I have the following stack trace: |
|
@9emE0iL18gxCqLT Are you using AWS ELB? |
|
@Lukasa No. Just a locally run Python script that does simple HTTP requests. I'm on a Kubuntu GNU/Linux x86_64 desktop. |
|
That's genuinely bizarre. Can you try reinstalling your copy of Requests? (You'll have to delete it first). There's just no way you can hit that exception, because it's inside a try/except block for exactly that purpose. |
|
@Lukasa I've reinstalled requests after I deleted it first, and installed it with sudo pip install git+git://github.com/kennethreitz/requests.git . I get exactly the same TypeError, that is: |
|
@Lukasa httplib.HTTPConnection.getresponse() doesn't accept any keyword arguments in Python 3.3 See:
The comments are incorrect in /usr/local/lib/python3.3/dist-packages/requests/packages/urllib3/connectionpool.py line 290: try: # Python 2.7+, use buffering of HTTP responses
httplib_response = conn.getresponse(buffering=True)
except TypeError: # Python 2.6 and older
httplib_response = conn.getresponse()I'll try to send a fix to urllib3. |
|
I agree that the comments are incorrect, but the except block should still catch the TypeError, which is why I'm confused. =) |
Well, it is caught, however another exception occurs. For @9emE0iL18gxCqLT it's |
|
Yeah, maybe. It does make the stack trace so much harder to read, though. =( At least in this case. |
|
Given the popularity of duck-typing in Python, we're going to run into this in all kinds of codebases. Maybe that's a piece of feedback that should go on the Python dev mailing list. :) |
|
That's an excellent idea. I'll look through the logs from that list to see if anyone mentioned it. |
|
I now have the exact same issue with my app on both my windows development and Openshift production servers. I am using Python 3.3 and Requests 2.1. It happens about 30%-50% of the time so it's reasonably reproducible. It seems to happen more when I throw many threaded requests at the target website. I can provide any code to reproduce if you guys need it. Is there a fix on the way? I'm not sure where to go from here. thanks. |
|
After rereading this thread I see that there are different levels to this problem. I'm thinking I'm throwing to many requests to the target website and they are closing some of the connections causing the ugly exception. Unless anybody has any suggestions I guess I will try to minimize the number of requests at once. |
|
@mrfatboy I'm afraid that's all you can do: this is just an artefact of the library design on 3.3. |
|
I'm doing python 3.4.3 and Requests 2.8.0, not using SSL and getting this error. If you're looking how to reproduce this in a test case this happens when I execute a request to a query page which times out after 300 seconds; this is the SQL query - |
|
Sorry, @juliusakula, but what exactly is the bug here? Currently it's not clear that we're doing anything wrong: the remote server is closing the connection unexpectedly and we are reporting the event. What you should investigate is why the remote server is closing the connection. |
|
I just ran into this, and I respectfully disagree with the idea that this is a bug in Python rather than # Receive the response from the server
try:
# For Python 2.7+ versions, use buffering of HTTP
# responses
r = low_conn.getresponse(buffering=True)
except TypeError:
# For compatibility with Python 2.6 versions and back
r = low_conn.getresponse()(see: https://github.com/kennethreitz/requests/blob/master/requests/adapters.py#L403-L410) You could just as easily use: import sys
# Receive the response from the server
if sys.version_info >= (2, 7):
# For Python 2.7+ versions, use buffering of HTTP
# responses
r = low_conn.getresponse(buffering=True)
else:
# For compatibility with Python 2.6 versions and back
r = low_conn.getresponse()This would prevent the unwanted association of connection errors with an unrelated |
|
Using |
|
EAFP is indeed encouraged. However, in this case, it is less explicit (thus the need for comments, and the reason no one has noticed those comments are inaccurate), and it causes unrelated error exceptions to be chained to a control flow exception. If EAFP is more important to you than those considerations, that's your call. |
|
The reality is that there are too many cases where doing a version check is simply not sufficient. There are tons of Python platforms and implementations out there—things like Jython, PyPy, AppEngine, eventlet, etc. In fact, many of these platforms are not even stable like CPython might be—a broken feature might be a bug that gets fixed in a minor version bump which is completely incongruent with the CPython reference implementation. Eventually it just seems like it's safest to check if the feature is there and use it if it is, regardless of what version is being advertised. |
|
That is a good point. Are there any versions of Python wherein # Receive the response from the server
try:
r = low_conn.getresponse(buffering=True)
except TypeError:
r = None
if r is None:
r = low_conn.getresponse()I'll admit, it looks a bit confusing... |
|
@hwkns apparently it's undocumented, but Python 2 accepted |
|
I am bit new to Python. From python i am calling some Jira APIs, those were working fine for a month but suddenly started throwing error for connection aborted Using python 2.7.0. any suggestion please? Struggling for long Traceback (most recent call last): |
|
@sandeepnassa sorry, but this isn't the appropriate place to ask for help with that. Also, when you do find the right place, no one will be able to tell you why the Jira API is closing your connection without seeing your code. |
|
Thank you @daniel Hawkins for response. My concern is not about Jira API.. its about the same connection aborted issue error 10054.. we are discussing in this thread. through python i am calling those APIs. i can provide code if required |
|
@sandeepnassa That exception is caused by the machine hosting the URL you're using forcibly tearing the connection down. It is very hard to work out why that would be happening without extremely large amounts of detail. However, if they've been working fine for a month: did you update JIRA? They may have changed their API. |
|
Thanks @Lukasa for response So was looking for expert knowledge. BTW.. this is the header I am using to call those Jira restful APIs |
|
Do you have logs from the JIRA server? Those logs may tell you what's going on. To be clear, it's entirely possible that it is in your code, but it's extremely unlikely that requests is doing this wrong. |
|
Instead of doing a try except you could instead inspect.getargspec and check if the function actually accepts a buffering keyword argument. |
|
@zbyte64 except that doesn't work consistently across all versions of Python 3. 3.5 for example doesn't allow that to work as easily |
I'm getting a strange error when using Requests in Python 3.3 (other flavors of Python 3 do not get this error):
This automation has run for months on Python 3.2 and these errors have never occurred. I don't really know enough about requests to investigate this issue, but I'd be happy to help recreate the issue or debug if someone else can. Perhaps there's a bug in how Requests is handling HTTPS requests with Python 3.3? (Did 3.3 change how urllib works?...I don't know offhand...)
Again, I'm not getting any of these issues in Python 3.2 or Python 3.1. Please help! :)
The text was updated successfully, but these errors were encountered: