[Web-SIG] PEP 444 (aka Web3)

Benoit Chesneau bchesneau at gmail.com
Fri Sep 17 11:07:01 CEST 2010


On Thu, Sep 16, 2010 at 6:41 PM, Armin Ronacher
<armin.ronacher at active-4.com> wrote:

>>  4. The web3 spec says, "In case a content length header is absent the
>>     stream must not return anything on read. It must never request more
>>     data than specified from the client." but later it says, "Web3
>>     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.". I would be sad if web3
>>     did not support streaming uploads via Transfer-Encoding. One way to
>>     implement that would be to make the origin server handle read()
>>     transparently by returning '' on EOF, regardless of whether a
>>     Content-Length or a Transfer-Encoding header was provided.
>
> I was toying with the idea to have a websocket extension for web3 which
> would have solved my usecase for requests without a content-length header.
>  The problem with the content length of incoming data is quite complex and
> that seemed to be the solution that was easiest for everybody involved.
>
uh ? Since with Transfer-Encoding: chunked we know when the stream
end, I would be in favor of returning an EOF too at the end. Also most
of servers know when a stream end even if there is no content-length.
Maybe we could have a capability setting in environ that say if the
server support streaming or not. And in all cases returning EOF at the
end?

- benoît


More information about the Web-SIG mailing list