couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Date Fri, 24 Jul 2009 10:48:08 GMT
+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<jan@apache.org> wrote:
>
> On 24 Jul 2009, at 12:02, Jan Lehnardt wrote:
>
>>
>> On 24 Jul 2009, at 11:55, jan@apache.org 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
> --
>
>

Mime
View raw message