[
https://issues.apache.org/jira/browse/COUCHDB-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-1439:
--------------------------------------
Attachment: couchdb-1439_tests.patch
Add patch with tests about this issue.
> `key`, `startkey`, `endkey` query parameters seems to have valid json value
> for show/update handlers.
> -----------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-1439
> URL: https://issues.apache.org/jira/browse/COUCHDB-1439
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 1.2, 1.3
> Environment: Apache CouchDB 1.3.0a-d6ab08d-git
> Apache CouchDB 1.2.0a-0d8ddc8-git
> Reporter: Alexander Shorin
> Attachments: couchdb-1439_tests.patch
>
>
> CouchDB requires that values of query parameters with names: `key`,
> `startkey`, `endkey` be valid json value when request been catched by show or
> update handler. This behavior is expected for views and lists(as they works
> as proxy for views and views requires this values as valid json ones), but
> it's little surprising to see same behavior for shows and updates.
> It's easy to test with any show or update handler:
> ~ # curl -X PUT http://localhost:5984/app/_design/ddoc -d '{"shows":
> {"empty": "function(doc, req){return \"\"}"}, "updates": {"nothing":
> "function(doc, req){return [null, \"\"]}"}}'
> ~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=foo
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /app/_design/ddoc/_show/empty?key=foo HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 400 Bad Request
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Date: Tue, 13 Mar 2012 14:11:38 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 48
> < Cache-Control: must-revalidate
> <
> {"error":"bad_request","reason":"invalid_json"}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -v -X POST http://localhost:5984/app/_design/ddoc/_update/nothing?key=foo
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > POST /app/_design/ddoc/_update/nothing?key=foo HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 400 Bad Request
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Date: Tue, 13 Mar 2012 15:14:11 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 48
> < Cache-Control: must-revalidate
> <
> {"error":"bad_request","reason":"invalid_json"}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> while...
> ~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=%22foo%22
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /app/_design/ddoc/_show/empty?key=%22foo%22 HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Vary: Accept
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Etag: "3B14BLTA7M1G53XKHX7EP0JUO"
> < Date: Tue, 13 Mar 2012 14:12:20 GMT
> < Content-Type: application/json
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> Initially, I'd faced with such behavior only for `key` parameter. Digging
> deeper I've found[1] same thing for `startkey` and `endkey` parameters, but
> I've no idea how to explain their dependency well.
> [1]
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_httpd_external.erl;h=bfe77a329d569bcc48cb65d8251a437baf13fae6;hb=HEAD#l110
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
