- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 11 May 2011 09:53:24 +0200
- To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, May 11, 2011 at 08:16:25AM +0100, Ben Niven-Jenkins wrote: > > Implementations MUST NOT rely on the ability to receive an incomplete > > message body. Full or partial message buffering by intermediaries or > > application servers, as well as re-chunking MAY impact user experience > > (eg: progress bar sent at once, or streamed video starting when fully > > transferred), but MUST NOT break the intended use. As such, applications > > MUST NOT expect bessage bodies to be usable as a bidirectional stream > > over which conversations are interleaved between the user-agent and the > > origin server. > > Looks generally good but it's not clear (to me at least) what "MUST NOT > break the intended use" refers to. What I meant is that whatever service the application in intends to serve, the effect of buffering must not stop the application from working. Example 1: video streaming sent by chunks might start playing only once download is complete. However, once transferred, it works, so even if this causes discomfort to the end user, it does not break the original goal of the application. Example 2: an application which sends exactly one image in each chunk, hoping for the recipient to use chunks as delimiters might break if an intermediary rechunks them. Example 3: an application which is based on short request-response transfers inside a single message body has a lot of chances to break once any intermediary buffers. I don't know if it's clearer now. Probably we'd find a better rewording. Willy
Received on Wednesday, 11 May 2011 07:53:50 UTC