couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Date Fri, 24 Jul 2009 12:11:03 GMT
2009/7/24 Jan Lehnardt <jan@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

Mime
View raw message