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