+1 to send non-chunked responses (at least, by default) if the exact size is known up front.
The only reason for a chunked response is when you don't know the size, afaik. Clients can use the content-length header for progress and resume (assuming couchdb/mochiweb supports Range?). B. On Fri, Jul 24, 2009 at 11:44 AM, Jan Lehnardt<[email protected]> wrote: > > On 24 Jul 2009, at 12:02, Jan Lehnardt wrote: > >> >> On 24 Jul 2009, at 11:55, [email protected] wrote: >> >>> Author: jan >>> Date: Fri Jul 24 09:55:09 2009 >>> New Revision: 797400 >>> >>> URL: http://svn.apache.org/viewvc?rev=797400&view=rev >>> Log: >>> comment on jchris comment on not sending Content-Length for attachment >>> GETs >> >> Chris, or anyone: >> >>> --- couchdb/trunk/src/couchdb/couch_httpd_db.erl (original) >>> +++ couchdb/trunk/src/couchdb/couch_httpd_db.erl Fri Jul 24 09:55:09 2009 >>> @@ -824,7 +824,9 @@ >>> % My understanding of http://www.faqs.org/rfcs/rfc2616.html >>> % says that we should not use Content-Length with a chunked >>> % encoding. Turning this off makes libcurl happy, but I am >>> - % open to discussion. >>> + % open to discussion. (jchris) >>> + % >>> + % Can you point to the section that makes you think >>> that? (jan) >>> % {"Content-Length", >>> integer_to_list(couch_doc:bin_size(Bin))} >> >> I couldn't find any reference to that. > > cmlenz:jan____: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 > cmlenz:"Messages MUST NOT include both a Content-Length header field and a > non-identity transfer-coding. If the message does include a non- identity > transfer-coding, the Content-Length MUST be ignored." > > okay. > > Not sending a Content-Length header causes a browser, when downloading an > attachment, to display "downloaded X bytes from ?". It is impossible to > track progress. Granted, this is a minor usability issues, but I'd like to > see this fixed. > > One solution would be to not use chunked encoding for responses. Does our > current send_* infrastructure support that without buffering the attachment > fully? If not, should we fix that? > > Or should we just not care and leave the status quo? > > If we change to non-chunked by default, I'd opt for a ?chunked=true option > (& request header, if there's one fitting) for those who like chunked > responses. > > Thoughts? > > Cheers > Jan > -- > >
