couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shorin (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (COUCHDB-1439) `key`, `startkey`, `endkey` query parameters seems to have valid json value for show/update handlers.
Date Tue, 13 Mar 2012 15:28:50 GMT
`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

        

Mime
View raw message