django/daphne
1
1
Fork 0
mirror of https://github.com/django/daphne.git synced 2025-07-11 08:22:17 +03:00
Code Issues Packages Projects Releases Wiki Activity

HTTP body spec fixes

Browse Source
This commit is contained in:
Andrew Godwin 2016-01-02 22:59:09 -08:00
parent 4847403ba0
commit 93b2229b2b
1 changed files with 4 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/asgi.rst
View File

@ -783,8 +783,10 @@ The ``start_response`` callable maps similarly to Response:
* The ``status`` argument becomes ``status`` and ``status_text`` * The ``status`` argument becomes ``status`` and ``status_text``
* ``response_headers`` maps to ``headers`` * ``response_headers`` maps to ``headers``
The main difference is that ASGI is incapable of performing streaming It may even be possible to map Request Body Chunks in a way that allows
of HTTP body input, and instead must buffer it all into a message first. streaming of body data, though it would likely be easier and sufficient for
many applications to simply buffer the whole body into memory before calling
the WSGI application.
Common Questions Common Questions
@ -801,14 +803,8 @@ Common Questions
TODOs TODOs
===== =====
* Work out if we really can just leave HTTP body as byte string. Seems too big.
Might need some reverse-single-reader chunking? Or just say channel layer
message size dictates body size.
* Maybe remove ``http_version`` and replace with ``supports_server_push``? * Maybe remove ``http_version`` and replace with ``supports_server_push``?
* Be sure we want to leave HTTP ``get`` and ``post`` out.
* ``receive_many`` can't easily be implemented with async/cooperative code * ``receive_many`` can't easily be implemented with async/cooperative code
behind it as it's nonblocking - possible alternative call type? behind it as it's nonblocking - possible alternative call type?
Asyncio extension that provides ``receive_many_yield``? Asyncio extension that provides ``receive_many_yield``?