-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
WSGI support is not spec conformant #29
Comments
Using def app(env, start_response):
start_response('200 OK', [('Content-Type','text/html'), ('Content-Length', '300')])
return Response([b"Hello", b" ", b"World"]) should not hang the server, from https://peps.python.org/pep-3333/#handling-the-content-length-header
|
|
If I am reading the code correctly, the whole response is also evaluated at once: Line 56 in 653f93a
It would be better to write that back in a streaming fashion. |
https://peps.python.org/pep-3333/#handling-the-content-length-header also says
So I think you can also ignore Content-Length and automatically determine Content-Length, instead of closing the connection (with is a more pleasing experience for everyone I think) |
No you shouldn't ignore the Content-Length header, if it is there you are supposed to use it. This is especially important for streaming larger respones where the iterable doesn't have a length of 1 (like in my example above). That said, my example is flawed since I do not implement support for My example about closing the connection was mostly about setting content length to 300 when the actual payload was "hello world" (ie shorter than 300). In this case the server has no good option but to close the connection since it would already have written "hello world" to the wire (in an ideal case) when it realizes that the rest of the data does not come. |
You are right. |
The issue with closing the response iterator is now fixed, so I'm closing this. In regards to supporting iteration over responses, you can open up a dedicated issue. |
From a quick look I do not think your fix works. `b"".join(rv)` could throw an exception and if that happens you are no calling close. If I remember the spec correctly you must call close even in case of errors.
…On Fri, Jan 13, 2023, at 02:35, Giovanni Barillari wrote:
The issue with closing the response iterator is now fixed, so I'm closing this.
In regards to supporting iteration over responses, you can open up a
dedicated issue.
—
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAT5C2NZQLRNW7ASBJOLN3WSCWNVANCNFSM6AAAAAATT4SZ3M>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I wanted to give granian a try but WSGI support seems to be somewhat out of spec. Eg try:
When running this, "Hello World" is returned properly but
.close()
is not called, see https://peps.python.org/pep-3333/#specification-detailsThe text was updated successfully, but these errors were encountered: