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:37:44 GMT
2009/7/24 Benoit Chesneau <bchesneau@gmail.com>:
> 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
>

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

Mime
View raw message