You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Alexander Shorin (Created) (JIRA)" <ji...@apache.org> on 2012/03/13 16:28:50 UTC
[jira] [Created] (COUCHDB-1439) `key`, `startkey`, `endkey` query
parameters seems to have valid json value for show/update handlers.
`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
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
[jira] [Updated] (COUCHDB-1439) `key`, `startkey`, `endkey` query
parameters seems to have valid json value for show/update handlers.
Posted by "Alexander Shorin (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (COUCHDB-1439) `key`, `startkey`, `endkey` query
parameters seems to have valid json value for show/update handlers.
Posted by "James Howe (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229098#comment-13229098 ]
James Howe commented on COUCHDB-1439:
-------------------------------------
FWIW this sounds like good behaviour. If parameters have the same name then they should behave in the same way, and people shouldn't be encouraged to break that convention. If you need a parameter that behaves differently then you should give it a different name.
> `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