[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