Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.newson@gmail.com
 designates 209.85.218.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=l9JeJ3KGXAr/8hev3xlbifvmfGkYXThutllSBLj4lMSV6IGPme3BVWAkiYPk1wTuFf
         4+LNzOegOa4VKDjPUBuEC5CMBCNUWO0BfJqXbixMip8nq3cyrdcuZmEExbOodlTfSCkv
         /ia8H4mP2SEM1jW6EPHzAt8S1L6JeVFrb3ut4=
MIME-Version: 1.0
In-Reply-To: <3C1BAF99-74A3-4084-AF8F-0843110E32A8@apache.org>
References: <20090724095509.72810238889B@eris.apache.org>
	 <F24EFAA2-AF7D-479B-9EAF-3D52651ED10F@apache.org>
	 <3C1BAF99-74A3-4084-AF8F-0843110E32A8@apache.org>
Date: Fri, 24 Jul 2009 11:48:08 +0100
Message-ID: <46aeb24f0907240348q3dae0dc9i93172418394b5e37@mail.gmail.com>
Subject: Re: svn commit: r797400 -
 /couchdb/trunk/src/couchdb/couch_httpd_db.erl
From: Robert Newson <robert.newson@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+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, afa=
ik.

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=3D797400&view=3Drev
>>> 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 20=
09
>>> @@ -824,7 +824,9 @@
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 % My understanding of http://www.faqs.org/r=
fcs/rfc2616.html
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 % says that we should not use Content-Lengt=
h with a chunked
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 % encoding. Turning this off makes libcurl =
happy, but I am
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% open to discussion.
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% open to discussion. (jchris)
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0%
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% Can you point to the section that ma=
kes you think
>>> that? (jan)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 % {"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#sec=
4.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 t=
o
> see this fixed.
>
> One solution would be to not use chunked encoding for responses. Does our
> current send_* infrastructure support that without buffering the attachme=
nt
> 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=3Dtrue opt=
ion
> (& request header, if there's one fitting) for those who like chunked
> responses.
>
> Thoughts?
>
> Cheers
> Jan
> --
>
>