-
-
Notifications
You must be signed in to change notification settings - Fork 810
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
Fix support for generator-based WSGI apps #887
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks! I checked out the code locally and it looks good (tests are failing without the fix). Left some suggestions here to reuse existing tests.
I removed the "Content-length" header from the tests because it isn't actually used anywhere in the code, and if people look at the tests as an example, it might be misleading. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Singletoned! Just left a question regarding an edge case
Relevant section of PEP 3333 for reference:
However, the start_response callable must not actually transmit the response headers. Instead, it must store them for the server or gateway to transmit only after the first iteration of the application return value that yields a non-empty bytestring, or upon the application's first invocation of the write() callable. In other words, response headers must not be sent until there is actual body data available, or until the application's returned iterable is exhausted. (The only possible exception to this rule is if the response headers explicitly include a Content-Length of zero.)
This delaying of response header transmission is to ensure that buffered and asynchronous applications can replace their originally intended output with error output, up until the last possible moment. For example, the application may need to change the response status from "200 OK" to "500 Internal Error", if an error occurs while the body is being generated within an application buffer.
Co-Authored-By: Florimond Manca <florimond.manca@gmail.com>
Co-Authored-By: Florimond Manca <florimond.manca@gmail.com>
Co-Authored-By: Florimond Manca <florimond.manca@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All set on my side once this last fix is in! 👍
Thank you so much!
Co-Authored-By: Florimond Manca <florimond.manca@gmail.com>
The WSGI adapter was trying to take the status code from
start_response
straightaway, rather than waiting until the first non-empty chunk, as per the spec: https://www.python.org/dev/peps/pep-3333/#the-start-response-callableI've made a small change that iterates through the response until it gets a non-empty chunk, and then passes everything on as normal. I've also added a test for that scenario.