-
-
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
ASGI Streaming response contains extra content #1730
Comments
I figured out that the extra content is the number of bytes in the chunk.
I turned chunking off (return stream(stream_file,chunked=False) and it works. Its not clear to me if this actually a bug or I'm doing something wrong. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions. |
I cannot even run the testcase code on current Sanic master because it tries to send headers as data. This is because asgi.py calls StreamingHTTPResponse.stream, which does However, this is one of the parts rewritten in #1791 (the |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions. |
Still broken in master! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions. |
I have some code that makes an http request (aiohttp) to an separate service to retrieve a file and then stream that file back. It is essentially acting as a proxy for this request. However, the streaming portion ends up wrapping some additional bytes of data around the body that I don't quite understand.
Here is a test case:
I run this code with 'uvicorn test:app --port 9000'
There are two endpoints / and /test2:
The actual response looks like:
That '33d' and '0' should not be there, but I don't see where they are coming from. Am I passing the stream along improperly?
The environment is OSX 10.15.1
One note is that I have applied the small snippet of code I described in #1653 in order to make the initial file stream work.
The text was updated successfully, but these errors were encountered: