encode / requests-async

async-await support for `requests`. ✨ 🍰 ✨

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Streaming request uploads and response downloads.

tomchristie opened this issue · comments

Not currently supported.
We can do at some point, but I think we should defer it at the moment.

It's more complicated than some other issues, because it'd mean minor API changes (eg. exactly what kind of interface do we expose for streaming downloads?)

Also for downloads we might end up having to stop using urllib3 responses, and handle some bits (eg. gzip decompression) ourselves.

Ideally we should:

  • Raise an error is stream=True is set.
  • Figure out how we can detect if a streaming request is being attempted, and handle any error conditions there neatly.

I ended up here looking for a solution to the blocking nature of iter_lines(). I'd prefer an asyncio version :)

response = requests.get("http://someserver/events", auth=some_auth, stream=True)
for line in response.iter_lines():
    ...

I need to check a exit_now = threading.Event() and stop watching the stream once it's set.
I have been looking for some way to tell if iter_lines() would block before calling it; I can't find it. I guess this is also why this is difficult to implement in requests-async.

Setting timeout=(3.0, 0.5) on the requests.get() just yields a ConnectionError (which is actually a ReadTimeoutError) and subsequent calls to the previous iterator or response.iter_lines() just throws a requests.exceptions.StreamConsumerError. I am guessing this is also what you were faced with.

Did you find a solution to get out of iter_lines() jail without losing the response? If so, what is it?

i'm currently using requests for download stuff, and i decided to upgrade to async version. But i understand that this library does not yet support stream downloads. I'm really expecting that stream support will be added soon.

According to the requests issue comments some problems (likely the ones affecting this issue) cannot be fixed in v2 because they will need to (for example) raise some sort of TimeoutError and existing code will likely not have a catch for that so they are putting the fixes off until v3.

I just used aiohttp to solve my issues. Too bad because I don't want our project to carry both dependencies. We will likely refactor away from requests so our project can move forward.

There’s no fundamental problems in resolving this - it just needs a bit of work.

Currently i'm using aiohttp and its got some memory leaks, thats why i'm looking for other alternatives. Hope you can make it work

Now resolved.
See README for the documentation.

Wow thank you sir. Will test soon.