You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by ja...@apache.org on 2009/07/24 11:55:09 UTC
svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
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
Modified:
couchdb/trunk/src/couchdb/couch_httpd_db.erl
Modified: couchdb/trunk/src/couchdb/couch_httpd_db.erl
URL: http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_httpd_db.erl?rev=797400&r1=797399&r2=797400&view=diff
==============================================================================
--- 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))}
]),
couch_doc:att_foldl(Att,
Re: svn commit: r797400 -
/couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Noah Slater <ns...@apache.org>.
On Sun, Jul 26, 2009 at 01:48:46PM -0400, Damien Katz wrote:
> I see no good reason for a http client to request a chunked encoding,
> it's easier and more efficient to deal with a content length than it is
> to parse out chunk segments. A good reason send a chunked encoding is it
> allows a Content-MD5 trailer to be computed on-the-fly. But I don't think
> we need to support the browser requesting a chunked encoding.
I've been following an interesting thread on the Content-MD5 header:
http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/thread.html#msg350
A select quote:
> After a quick look, my reading is that a Content-MD5 header on a
> partial response reflects the bytes in that message, rather than the
> whole (non-partial) response:
RFC2616 can apparently be read both ways depending on which parts of the
specs you read, which is a bit of a problem for Content-MD5.
- http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0277.html
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Damien Katz <da...@apache.org>.
On Jul 24, 2009, at 5:54 PM, Chris Anderson wrote:
> On Fri, Jul 24, 2009 at 12:58 PM, Christopher Lenz<cm...@gmx.de>
> wrote:
>> On 24.07.2009, at 14:37, Benoit Chesneau wrote:
>>>
>>> Reading the spec and with feedback from cmlenz on irc, I'm changing
>>> my position for GET :)
>>>
>>> If content-length is know, I think CouchDB should send unchunked
>>> until
>>> the client don't ask for specific encoding with TE in headers and
>>> http
>>> version is 1.1 :
>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
>>
>> (Background: the one thing chunked encoding gives you over "identity"
>> encoding with a Content-Length header is that you can detect some
>> kind of
>> data corruptions before having consumed the entire response. Benoit
>> noted
>> that this was important to him.)
>>
>> I can't really figure out a nice way to have the client request
>> chunked
>> encoding. "TE: chunked; q=1" is implicit in HTTP/1.1, so how would
>> a client
>> say: "really, I'd prefer chunked encoding"?
>>
>> We *could* have CouchDB use chunked encoding for attachments GETs
>> only when
>> "TE: chunked" is specified, but that'd be a proprietary hack, AFAICT.
>>
>> There's also "TE: trailers" to indicate that the client supports
>> trailers in
>> chunked responses. We could base the decision on that header, but
>> that'd be
>> just as much of a hack IMO.
>>
>> Maybe a query string parameter really is the way to go here?
>>
>
> Agreed with all of the above. I was just looking at that the other
> day. We should switch to unchunked by default, with a Content-Length
> header.
>
> As far as retaining the ability to serve chunked, I think a query
> parameter is as sane a way as any.
>
> I'd love to see this patch come from someone else, as I've been
> working on that code path a lot lately and it could use someone else's
> eyes.
>
> I think we should mark this blocking for 0.10, as it's so easy and the
> ? thing makes it a user-facing feature.
Yes, there is no need for it to be chunked. I remember at some point I
tried switch it to regular encoding, but it caused errors in the
replicator and I never got around to debugging it.
I see no good reason for a http client to request a chunked encoding,
it's easier and more efficient to deal with a content length than it
is to parse out chunk segments. A good reason send a chunked encoding
is it allows a Content-MD5 trailer to be computed on-the-fly. But I
don't think we need to support the browser requesting a chunked
encoding.
-Damien
>
> Chris
>
>
>> Cheers,
>> --
>> Christopher Lenz
>> cmlenz at gmx.de
>> http://www.cmlenz.net/
>>
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Chris Anderson <jc...@apache.org>.
On Fri, Jul 24, 2009 at 12:58 PM, Christopher Lenz<cm...@gmx.de> wrote:
> On 24.07.2009, at 14:37, Benoit Chesneau wrote:
>>
>> Reading the spec and with feedback from cmlenz on irc, I'm changing
>> my position for GET :)
>>
>> If content-length is know, I think CouchDB should send unchunked until
>> the client don't ask for specific encoding with TE in headers and http
>> version is 1.1 :
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
>
> (Background: the one thing chunked encoding gives you over "identity"
> encoding with a Content-Length header is that you can detect some kind of
> data corruptions before having consumed the entire response. Benoit noted
> that this was important to him.)
>
> I can't really figure out a nice way to have the client request chunked
> encoding. "TE: chunked; q=1" is implicit in HTTP/1.1, so how would a client
> say: "really, I'd prefer chunked encoding"?
>
> We *could* have CouchDB use chunked encoding for attachments GETs only when
> "TE: chunked" is specified, but that'd be a proprietary hack, AFAICT.
>
> There's also "TE: trailers" to indicate that the client supports trailers in
> chunked responses. We could base the decision on that header, but that'd be
> just as much of a hack IMO.
>
> Maybe a query string parameter really is the way to go here?
>
Agreed with all of the above. I was just looking at that the other
day. We should switch to unchunked by default, with a Content-Length
header.
As far as retaining the ability to serve chunked, I think a query
parameter is as sane a way as any.
I'd love to see this patch come from someone else, as I've been
working on that code path a lot lately and it could use someone else's
eyes.
I think we should mark this blocking for 0.10, as it's so easy and the
? thing makes it a user-facing feature.
Chris
> Cheers,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
>
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Christopher Lenz <cm...@gmx.de>.
On 24.07.2009, at 14:37, Benoit Chesneau wrote:
> Reading the spec and with feedback from cmlenz on irc, I'm changing
> my position for GET :)
>
> If content-length is know, I think CouchDB should send unchunked until
> the client don't ask for specific encoding with TE in headers and http
> version is 1.1 :
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
(Background: the one thing chunked encoding gives you over "identity"
encoding with a Content-Length header is that you can detect some kind
of data corruptions before having consumed the entire response. Benoit
noted that this was important to him.)
I can't really figure out a nice way to have the client request
chunked encoding. "TE: chunked; q=1" is implicit in HTTP/1.1, so how
would a client say: "really, I'd prefer chunked encoding"?
We *could* have CouchDB use chunked encoding for attachments GETs only
when "TE: chunked" is specified, but that'd be a proprietary hack,
AFAICT.
There's also "TE: trailers" to indicate that the client supports
trailers in chunked responses. We could base the decision on that
header, but that'd be just as much of a hack IMO.
Maybe a query string parameter really is the way to go here?
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Benoit Chesneau <bc...@gmail.com>.
2009/7/24 Benoit Chesneau <bc...@gmail.com>:
> 2009/7/24 Jan Lehnardt <ja...@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
>> --
>>
>>
>
> I would be to handle streaming on chunked encoding and without chunks.
> Using chunked encoding for streaming is good since it allow server to
> make sure it get the right length for each chunks.
>
>
> The problem is the same for attachements PUT anyway. Actually by
> default couchdb try to receive the request with Length then chunked.
> Like said on irc, this is the error I had with couchapp on couch.io .
> It was sending both Transfer-Encoding and Content-Length and apache
> raise a 500 error (should be 400 ama). I think that couchdb should
> raise a bad request error (400) when both are in headers and then
> check if headers contain chunked or Length like the rfc recommand.
> Also case where a bad request is sent (Transfer-encoding: chunked but
> body isn't) should be handle too.
>
> So for put something like :
> case MochiReq:body_length() of
> chunked-> recv_body_chunked(...
> Length -> recv_body_unchuked(..
> end
>
> should od the trick. For GET the problem is different. If http version
> of client is 1.0, content should be sent unchunked (so with
> Content-Length), if client is 1.1, chunked encoding should be
> preferred.
>
> - benoit
>
Reading the spec and with feedback from cmlenz on irc, I'm changing
my position for GET :)
If content-length is know, I think CouchDB should send unchunked until
the client don't ask for specific encoding with TE in headers and http
version is 1.1 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
But still there are currently problem with PUT, if transfert-encoding
is set not content-length should be present in headers. Or at least
Couchdb should handle the possibility that request is sent with bad
encoding and raise an error rather than waiting the end of request.
- benoit
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Benoit Chesneau <bc...@gmail.com>.
2009/7/24 Jan Lehnardt <ja...@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
> --
>
>
I would be to handle streaming on chunked encoding and without chunks.
Using chunked encoding for streaming is good since it allow server to
make sure it get the right length for each chunks.
The problem is the same for attachements PUT anyway. Actually by
default couchdb try to receive the request with Length then chunked.
Like said on irc, this is the error I had with couchapp on couch.io .
It was sending both Transfer-Encoding and Content-Length and apache
raise a 500 error (should be 400 ama). I think that couchdb should
raise a bad request error (400) when both are in headers and then
check if headers contain chunked or Length like the rfc recommand.
Also case where a bad request is sent (Transfer-encoding: chunked but
body isn't) should be handle too.
So for put something like :
case MochiReq:body_length() of
chunked-> recv_body_chunked(...
Length -> recv_body_unchuked(..
end
should od the trick. For GET the problem is different. If http version
of client is 1.0, content should be sent unchunked (so with
Content-Length), if client is 1.1, chunked encoding should be
preferred.
- benoit
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Patrick Aljord <pa...@gmail.com>.
there:
http://redbot.org/?uri=http%3A%2F%2Fjchrisa.net%2Fdrl%2Fp2p-Web-OSCON%2FCouchDB-OSCON.pdf
Re: svn commit: r797400 -
/couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jul 24, 2009 at 12:44:13PM +0200, Jan Lehnardt wrote:
> 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."
Has anyone tested CouchDB with RED:
http://redbot.org/
Might provide some useful pointers.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Jan Lehnardt <ja...@apache.org>.
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<ja...@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
>> --
>>
>>
>
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Robert Newson <ro...@gmail.com>.
+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?).
B.
On Fri, Jul 24, 2009 at 11:44 AM, Jan Lehnardt<ja...@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
> --
>
>
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Jan Lehnardt <ja...@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
--
Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Posted by Jan Lehnardt <ja...@apache.org>.
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.
Cheers
Jan
--