On Fri, Jul 24, 2009 at 12:58 PM, Christopher Lenz<[email protected]> wrote: > On 24.07.2009, at 14:37, Benoit Chesneau wrote: >> >> Reading the spec and with feedback from cmlenz on irc, I'm changing >> my position for GET :) >> >> If content-length is know, I think CouchDB should send unchunked until >> the client don't ask for specific encoding with TE in headers and http >> version is 1.1 : >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39 > > (Background: the one thing chunked encoding gives you over "identity" > encoding with a Content-Length header is that you can detect some kind of > data corruptions before having consumed the entire response. Benoit noted > that this was important to him.) > > I can't really figure out a nice way to have the client request chunked > encoding. "TE: chunked; q=1" is implicit in HTTP/1.1, so how would a client > say: "really, I'd prefer chunked encoding"? > > We *could* have CouchDB use chunked encoding for attachments GETs only when > "TE: chunked" is specified, but that'd be a proprietary hack, AFAICT. > > There's also "TE: trailers" to indicate that the client supports trailers in > chunked responses. We could base the decision on that header, but that'd be > just as much of a hack IMO. > > Maybe a query string parameter really is the way to go here? >
Agreed with all of the above. I was just looking at that the other day. We should switch to unchunked by default, with a Content-Length header. As far as retaining the ability to serve chunked, I think a query parameter is as sane a way as any. I'd love to see this patch come from someone else, as I've been working on that code path a lot lately and it could use someone else's eyes. I think we should mark this blocking for 0.10, as it's so easy and the ? thing makes it a user-facing feature. Chris > Cheers, > -- > Christopher Lenz > cmlenz at gmx.de > http://www.cmlenz.net/ > > -- Chris Anderson http://jchrisa.net http://couch.io
