Update WSGIWrapper to be spec compliant (pep 333/3333).

[apollo13]

The commit contains the following changes:

• Error out early if the application forgets to call start_response
• Send a proper content-length if the iterable returned has only one item
• Always call close() on the returned iterable if it exists.

This potentially fixes #154. Haven't looked at tests yet, but should provide a base for discussion…

[apollo13]

@pgjones Could you reapprove that workflow? I have added a few tests and improved the code so no unnecessary http.response.body events are sent. Let me know what you think.

For what it is worth I'd consider this a rather critical bug. Not calling .close() will not properly clean up connections in Django but might close them during gc collection in subsequent requests, leading to hard to debug errors.

[pgjones]

Thanks, I've taken a different approach in 2d2c62b.

I've tested other implementations and gunicorn and I don't believe any others set the content-length (rather they'll use chunked transfer encoding). So I've decided against this to avoid the complexity. As I understand PEP 3333 considers this optional.

[apollo13]

Mhm, yeah as long as the framework sets Content-Length then gunicorn (and hypercorn) will happily serve it as such without chunking, so I guess the "optimization" would have only applied if the framework didn't set the content length and is probably not worth it. Sorry for opening the PR prematurely, should have waited to hear your thoughts.

[pgjones]

Thanks for opening the PR, it was very helpful - sorry I didn't merge it directly. I'm often conflicted between accepting the PR as is, and wanting it to match "my style" - I usually try both (merge the PR then add a commit adjusting it).

[apollo13]

No worries, the most important thing is that the underlying issue is fixed and we have one hard issue less to debug in Django. That said I wonder if it would make sense to utilize https://github.com/abersheeran/a2wsgi instead, though that would need trio support first (maybe through anyio). This way we would only need to improve the asgi -> wsgi mapping in one place (uvicorn uses it as well). Maybe @abersheeran can chime in as well.

…

On Wed, Dec 27, 2023, at 23:35, Phil Jones wrote: Thanks for opening the PR, it was very helpful - sorry I didn't merge it directly. I'm often conflicted between accepting the PR as is, and wanting it to match "my style" - I usually try both (merge the PR then add a commit adjusting it). — Reply to this email directly, view it on GitHub <#155 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAT5C4MLBVWBJN4J7AYVM3YLSPB3AVCNFSM6AAAAAA7IFCATOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGY3DQNJZGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[pgjones]

I can't add any more dependencies if I want Hypercorn to be considered as the replacement for the Werkzeug development server. Happy to work with a2wsgi though and link to it in the docs.