- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Mon, 29 Apr 2013 16:39:01 -0500
- To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CACuKZqExu7+bnkECyVhVvK6SUeptVO-beqi6t18gJiAfc=PSbg@mail.gmail.com>
On Mon, Apr 29, 2013 at 1:47 PM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>wrote: > Hi, > > The p1 HTTPbis draft has removed using multipart/byteranges as a message > delimiter in 206 responses (which was previously allowed by RFC2616). > > I see this was originally tracked as Ticket #90 and the outcome was to > deprecate such behaviour in all cases including in 206 responses with > Content-Type: multipart/byteranges (which is the only case I care about). > > This decision makes previously conforming implementations (such as our > reverse proxy implementation) now non-conformant and the alternatives of: > (A) close connection after every multipart/byteranges response or (B) > pre-calculate message body length (including header/boundary bytes for each > byterange) in advance, are inconvenient. > What about (C) apply chunked coding on response body? It might be easier than calculating Content-Length. Zhong Yu > Would it be possible to re-allow use of multipart/byteranges as a message > delimiter in the case where it is a 206 response AND there is no > Transfer-Encoding AND there is no Content-Length so that implementations > such as ours are classed as conformant again? > > > Even if it is decided to stick with the current state of affairs in -22 > where generating 206 responses that use multipart/byteranges as a delimiter > is forbidden, the specification should still specify how to parse such > responses in a backwardly compatible manner as generating such responses > was previously allowed & used and so User Agents should still expect to > receive them from pre-httpbis implementations. > > Thanks > Ben > > >
Received on Monday, 29 April 2013 21:39:28 UTC