On Thu, Sep 16, 2010 at 6:41 PM, Armin Ronacher <armin.ronac...@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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
