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.
--
http://mail.python.org/mailman/listinfo/python-list
