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