Streaming templating languages for use as WSGI body.

Thu Jan 6 17:33:29 EST 2011

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.