couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Date Fri, 24 Jul 2009 10:56:05 GMT

On 24 Jul 2009, at 12:48, Robert Newson wrote:

> +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?).

We don't support range yet, but there's a JIRA ticket for that :)

Cheers
Jan
--


>
> 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