Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <3C1BAF99-74A3-4084-AF8F-0843110E32A8@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <F24EFAA2-AF7D-479B-9EAF-3D52651ED10F@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: svn commit: r797400 -
 /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Date: Fri, 24 Jul 2009 12:44:13 +0200
References: <20090724095509.72810238889B@eris.apache.org>
 <F24EFAA2-AF7D-479B-9EAF-3D52651ED10F@apache.org>


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