streaming output

[Brogli]

Hi,
Is there an easy way to get a handle to the output file stream in a
Django application? Instead of building an entire response in memory
then sending it out, I'd like to send the response in pieces.

thanks,
Dave

[Malcolm Tredinnick]

Not really (in a reliable way). One constraint is that Django is
designed to operate seamlessly as a WSGI application and the WSGI
specification does not permit responses to be streamed in pieces
("chunked transfer encoding" in the HTTP 1.1 parlance) from an
application.

Yes, it's theoretically possible to pass a generator to the
HttpResponse, but there are lots of technical problems that can arise.
Some of which are being worked out on the dev list at the moment, some
of which are just technically impossible (like the WSGI constraint).

Regards,
Malcolm

[Joshua Jonah]

Not that i know of, but you'd be surprised how easy it is to write a
socket server in Python:

http://www.amk.ca/python/howto/sockets/

[Brogli]

Thanks for the information. I was hoping to use Django for all of the
web application I'm building (which requires a continuous stream of
data to the client rather than poling) though it appears I'll have to
build the streaming portion outside of Django, or perhaps modify the
server behavior to handle the stream URL at a low level in the
server. I'm not really too excited about having to essentially build
another web server and run it on another port so I'm looking at
modifying (subclassing actually) basehttp.ServerHandler to expose the
output stream. This seems to work for this low level requirement,
though obviously using the stream directly is dangerous within the
higher level components.

thanks,
Dave

[Brogli]

PEP 333 indicates chunked encoding is ok in WSGI apps:

"And, if the server and client both support HTTP/1.1 "chunked
encoding" [3], then the server may use chunked encoding to send a
chunk for each write() call or string yielded by the iterable, thus
generating a Content-Length header for each chunk. This allows the
server to keep the client connection alive, if it wishes to do so.
Note that the server must comply fully with RFC 2616 when doing this,
or else fall back to one of the other strategies for dealing with the
absence of Content-Length."

So really Django's implementation of WSGI (or more specifically, the
middleware design assumptions) appear to be the limitation, not WSGI
itself per se.

regards,
Dave

On Jul 8, 7:42 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote: