Streaming templating languages for use as WSGI body.

[Alice Bevan–McGregor]

On 2011-01-06 11:11:27 -0800, Adam Tauno Williams said:
> On Thu, 2011-01-06 at 11:07 -0800, Alice Bevan–McGregor wrote:
>> On 2011-01-06 10:00:39 -0800, Adam Tauno Williams said:
>>> With HTTP/1.0 [and WSGI is HTTP/1.0 only] you have to provide a 
>>> Content-Length header - so you have to generate the entire response at 
>>> once [however you want to muddy "at once"].
>> 
>> Both of these statements are false.
> 
> Both these statements are true!  I suggest you consult the HTTP spec.

It's generally polite to provide direct references, either sections or 
actual links when asking someone to RTFM.  No matter, examining the 
HTTP/1.0 RFC (conveniently chopped up and HTML-ified by the w3) I find 
evidence to support your argument:

http://www.w3.org/Protocols/HTTP/1.0/draft-ietf-http-spec.html#Entity-Body

However, HTTP clients are smarter than the raw spec.  ;)

Run the code found at the following link and poke the wsgiref server 
that is run in a web browser, with curl, or any other HTTP tool, even 
telnet:

	http://pastie.textmate.org/1435415

You'll notice no content-length header (wsgiref adds one automatically 
for single-element iterables) and no difficulty in receiving the entire 
response body, even without a content-length.

The de-facto standard behaviour combined with the following text from 
WSGI makes streaming content with non-deterministic lengths completely 
reasonable:

> WSGI servers, gateways, and middleware must not delay the transmission 
> of any block; they must either fully transmit the block to the client, 
> or guarantee that they will continue transmission even while the 
> application is producing its next block.

Point me to a HTTP client from the last 10 years that doesn't handle 
this particular condition and I'll believe your original statements.   
:)

	- Alice.