-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
enable_compression causes exception on HTTP/1.0 #1828
Comments
Sorry, the "HTTP/1.1 is responsed with HTTP/1.0" is caused by a forwarding nginx. |
A related problem also exists on the client side: |
we do not know final size of payload, so it is just simpler to switch to chunked encoding. |
I am not interested in changing current behavior. we may use compression without chunking for simple web.Request but for streaming response it seems easier to allow developer to choose what he wants. @hubo1016 how would you fix this? |
@fafhrd91 I think compress with "Content-Encoding" should not affect the transfer encoding, they are on different layer. What is the expected behavior when sending a stream data without a specified length on a HTTP/1.0 connection? (According to RFC, the server should send a "Connection: close" header and shutdown the connection write side after all payload are sent, read and drop extra messages from the client which may be pipelining requests, then close the connection.) I will dig deeper when I have time. Maybe it is just simplier to create a speicifed "content" which is compressed, either as a fixed-length bytes or a stream. Then we use the exactly same tranfer technology to transfer the compressed payload acrossing the HTTP channel. |
@hubo1016 would you like to work on this issue? |
seems, nobody wants to work on this. I suggest to close. |
The issue in not in my priority list but please postpone the closing. |
@fafhrd91 Finally I have time for this issue, but firstly I want to read the existing codes and evaluate the effort. I will have a conclusion in a week. |
@fafhrd91 @asvetlov I have read the related code. The fix is quite straight-forward: instead of set _chunked directly, just remove the Content-Length header instead. Also the content-length property in Response class must be re-implemented to return the length of the compressed data. Still some more tests should be added for this new behavior, including tests with version set to HTTP/1.0. There is also some related issues and I need your opinions:
I will submit the pull request after reparing unittests. The current status can be viewed in hubo1016#2 |
@hubo1016 the "HTTP/1.1 is responsed with HTTP/1.0" is caused by a forwarding nginx. Why is that so and can it be fixed in the nginx config? |
@mickeyl our configuration did not set the http version, so it defaults to HTTP/1.0, it can be fixed by setting the http version. But I still think it should be fixed. |
Thanks, I have since found the neccessary |
Long story short
call set_compression() on a response object and return it to aiohttp server causes a RuntimeError ("Using chunked encoding is forbidden for HTTP/1.0")
Expected behaviour
There should be at least two ways to use compression on HTTP/1.0:
Actual behaviour
An runtime error is raised, and the connection is closed immediately.
In fact, it seems that by default, even a HTTP/1.1 request is responded with a HTTP/1.0 response, so it always raises this exception.
Steps to reproduce
Call enable_compression on any response object before returning.
Comment
I think it is absolutely not correct to enable chunked encoding on compression. Content-Encoding is not a part of transfer, it is a part of the content. It should never affect the transfer encoding type.
The text was updated successfully, but these errors were encountered: