[ 
https://issues.apache.org/jira/browse/COUCHDB-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322863#comment-14322863
 ] 

Samuel Tardieu commented on COUCHDB-2583:
-----------------------------------------

As I wrote above, ensuring that nothing is sent is problematic: that would 
require people to actually declare that they are sending "application/json" 
content while in fact they do not do so as the empty string is not strictly a 
valid "application/json" content. This is precisely why I used 
{{couch_httpd:body(Req)}} in the patch instead of 
{{couch_httpd:json_body(Req)}}, as the latter would have returned an error for 
an empty content despite the declared "application/json".

Forcing clients to declare a content-type when the content is not used is one 
thing, forcing them to generate invalid representations is another :)

An alternative would be to use {{http:json_body(Req)}} if the content length is 
not 0, to ensure that the transmitted content is valid json. But that would 
require handling the chunked request case as well and would not be trivial nor 
useful at this stage, and why refuse for example a content of one space 
(invalid JSON) when we accept an empty one (invalid JSON as well)?

In my opinion, the most sensible thing to do would be to accept anything in 
CouchDB 1.x, as not to break existing code and practices (for example, HTTP/1.0 
clients might already be sending valid JSON, as by default the connection is 
dropped after every command), and to require valid JSON content (for example an 
empty object) in CouchDB 2.x for those methods.

> ensure_full_commit requires empty but typed content or it will unexpectedly 
> drops the connection
> ------------------------------------------------------------------------------------------------
>
>                 Key: COUCHDB-2583
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2583
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: HTTP Interface
>    Affects Versions: 1.6.1
>            Reporter: Samuel Tardieu
>         Attachments: 0001-Consume-JSON-body-even-if-ignored.patch
>
>
> When given an non-empty (but valid) JSON content, some methods such as 
> {{_ensure_full_commit}} will abruptly drop a persistent connection instead of 
> waiting for a new HTTP request even though no error is signaled in CouchDB 
> logs:
> {code:title=Request}
> POST /testdb1/_ensure_full_commit HTTP/1.1
> Host: localhost:5984
> Accept: application/json
> Content-Type: application/json
> Content-Length: 2
> {}
> {code}
> {code:title=Response}
> HTTP/1.1 201 Created
> Server: CouchDB/1.6.1 (Erlang OTP/17)
> Date: Mon, 16 Feb 2015 11:49:11 GMT
> Content-Type: application/json
> Content-Length: 53
> Cache-Control: must-revalidate
> {"ok":true,"instance_start_time":"1424085277160411"}
> {code}
> [connection is closed without warning by CouchDB at this point]
> To remedy that, one could try to give an empty content, but some frameworks 
> (such as spray.io) will systematically omit the {{Content-Type}} header in 
> this case since it makes little sense to type empty content. However, CouchDB 
> will reject the request even though it does *not* want any content:
> {code:title=Request}
> POST /testdb1/_ensure_full_commit HTTP/1.1
> Host: localhost:5984
> Accept: application/json
> Content-Length: 0
> {code}
> {code:title=Response}
> HTTP/1.1 415 Unsupported Media Type
> Server: CouchDB/1.6.1 (Erlang OTP/17)
> Date: Mon, 16 Feb 2015 11:55:52 GMT
> Content-Type: application/json
> Content-Length: 78
> Cache-Control: must-revalidate
> {"error":"bad_content_type","reason":"Content-Type must be application/json"}
> {code}
> This makes it impossible to use those methods with such frameworks. CouchDB 
> should not drop the connection and ignore the data if {{Content-Length}} is 
> not 0, nor require that data be typed with {{application/json}} if it is 
> going to ignore it anyway or if it requires it to be empty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to