On Jul 17, 1:55 pm, Cad <f...@nabuma.com> wrote:
> I tried this:http://webpy.org/cookbook/streaming_large_files
> and it does work, but it just doesn't feel right. It works in firefox
> (loading the main page takes forever), but not in chrome (it loads it
> and then displays it all at once).
>
> I looked at the headers:
> HTTP/1.1 200 OK
>
> Content-type: text/html
>
> Transfer-Encoding: chunked
>
> Transfer-Encoding: chunked
>
> Date: Fri, 17 Jul 2009 05:37:37 GMT
>
> Server: CherryPy/3.1.2 WSGI Server
>
> It's sending transfer-encoding twice? I tried not setting the header
> in the code and it, oddly enough, still set transfer-encoding as
> chunked. It didn't work even then though... Am I missing something?
The WSGI specification says:
"""However, because WSGI servers and applications do not communicate
via HTTP, what RFC 2616 calls "hop-by-hop" headers do not apply to
WSGI internal communications. WSGI applications must not generate any
"hop-by-hop" headers [4], attempt to use HTTP features that would
require them to generate such headers, or rely on the content of any
incoming "hop-by-hop" headers in the environ dictionary."""
Further"
"""(Note: applications and middleware must not apply any kind of
Transfer-Encoding to their output, such as chunking or gzipping; as
"hop-by-hop" operations, these encodings are the province of the
actual web server/gateway. See Other HTTP Features below, for more
details.)"""
In other words, you should not be setting 'Transfer-Encoding' header
nor return data in a chunked format. Whether that is done is up to the
under web server.
"""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."""
The WSGI specification also says:
"""WSGI servers must handle any supported inbound "hop-by-hop" headers
on their own, such as by decoding any inbound Transfer-Encoding,
including chunked encoding if applicable."""
This one is a bit silly though really as the WSGI interface doesn't
really support chunked request content as a WSGI application is not
allowed to read more than CONTENT_LENGTH. When CONTENT_LENGTH is not
set, as will be case for chunked request content, then it is supposed
to deem length to be 0. Therefore technically can't read chunked
request data. Some WSGI servers fudge it by reading all the content
into a buffer and calculating CONTENT_LENGTH, but that sort of defeats
the purpose and can too easily block out memory use. Others will
enable acceptance of chunked request content, but you technically have
to violate the specification to read it. This is just one of the areas
where WSGI specification is deficient.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web.py" group.
To post to this group, send email to webpy@googlegroups.com
To unsubscribe from this group, send email to webpy+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/webpy?hl=en
-~----------~----~----~----~------~----~------~--~---
