Fix node-specific shard access via HTTP

[wohali]

Overview

In #2336 we removed node-local HTTP access and redirected all traffic through /_node/{node-name}/.... This sneakily routes a new MochiWeb request through to couch_httpd under the covers.

Unfortunately, in the process we ended up URL-decoding the URL, meaning the passed-through URL couldn't include %2F for accessing individual shards.

This reintroduces URL encoding to fix the problem.

It also introduces support to query a specific view shard through /_node/{node-name}/{db-shard}/{ddoc}/. This allows inspection of individual view shard sizes.

Testing recommendations

dev/run -n 1 -a admin:password
curl -X PUT http:https://admin:password@localhost:15984/abc
curl -X PUT http:https://admin:password@localhost:15984/abc/_design%2ffoo -d '{"language":"javascript","views":{"all":{"map":"function(doc) { emit(doc._id, null);}"}}}'
curl -X PUT http:https://admin:password@localhost:15984/abc/def -d '{}'
curl -X PUT http:https://admin:password@localhost:15984/abc/qqq -d '{}'
curl http:https://admin:password@localhost:15984/_node/_local/_all_dbs
# substitute your timestamp code in the following lines...
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580273428
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580273428/def
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580273428/qqq

curl http:https://admin:password@localhost:15984/abc/_design/foo/_info
curl http:https://admin:password@localhost:15984/abc/_design/foo/_view/all
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580273428/_design/foo/_info
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f80000000-ffffffff%2fabc.1580273428/_design/foo/_info
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580273428/_design/foo/_view/all
curl http:https://admin:password@localhost:15984/_node/_local/shards%2f80000000-ffffffff%2fabc.1580273428/_design/foo/_view/all

Example output for the last few lines (new per-view-shard endpoint):

$ curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580515057/_design/foo/_info
{"name":"foo","view_index":{"signature":"de76da589940694f05807f0c4fb5d33a","language":"javascript","sizes":{"file":4190,"active":98,"external":24},"update_seq":1,"purge_seq":0,"update_options":[],"updater_running":false,"compact_running":false,"waiting_commit":false,"waiting_clients":0,"pending_updates":0}}
$ curl http:https://admin:password@localhost:15984/_node/_local/shards%2f80000000-ffffffff%2fabc.1580515057/_design/foo/_info
{"name":"foo","view_index":{"signature":"de76da589940694f05807f0c4fb5d33a","language":"javascript","sizes":{"file":8292,"active":98,"external":24},"update_seq":2,"purge_seq":0,"update_options":[],"updater_running":false,"compact_running":false,"waiting_commit":false,"waiting_clients":0,"pending_updates":0}}

$ curl http:https://admin:password@localhost:15984/_node/_local/shards%2f00000000-7fffffff%2fabc.1580515057/_design/foo/_view/all
{"total_rows":1,"offset":0,"rows":[
{"id":"def","key":"def","value":null}
]}
$ curl http:https://admin:password@localhost:15984/_node/_local/shards%2f80000000-ffffffff%2fabc.1580515057/_design/foo/_view/all
{"total_rows":1,"offset":0,"rows":[
{"id":"qqq","key":"qqq","value":null}
]}

Related Issues or Pull Requests

Closes #2500 fully.

[nickva]

All the url types mentioned in the PR comments work but I did find an issue with attachments.

Here is what I did.

Setup:

http put $DB/deebee
http put $DB/deebee/dok a=b
http put $DB/deebee/dok2/att1 x=y
http put $DB/deebee/_design/dok k=l

These work:

http $DB/_node/_local/shards%2f80000000-ffffffff%2fdeebee.1580329759/_all_docs
http $DB/_node/_local/shards%2f80000000-ffffffff%2fdeebee.1580329759/dok
http $DB/_node/_local/shards%2f80000000-ffffffff%2fdeebee.1580329759/_design/dok

I am getting an undef error for attachments though:

http $DB/_node/_local/shards%2f80000000-ffffffff%2fdeebee.1580329759/dok2/att1
HTTP/1.1 500 Internal Server Error
Cache-Control: must-revalidate
Content-Length: 43
Content-Type: application/json
Date: Wed, 29 Jan 2020 20:33:31 GMT
Server: CouchDB/3.0.0-63ae7a56c (Erlang OTP/21)

{
    "error": "unknown_error",
    "reason": "undef"
}

The clustered version is:

http $DB/deebee/dok2

{
    "_attachments": {
        "att1": {
            "content_type": "application/json",
            "digest": "md5-3duf0qFWt+WP2oua5pLv7A==",
            "length": 10,
            "revpos": 1,
            "stub": true
        }
    },
    "_id": "dok2",
    "_rev": "1-223d72d872a9318f0764b49f0371c1d1"
}

http $DB/deebee/dok2/att1
{
    "x": "y"
}

Logs show this error:

[error] 2020-01-29T20:33:31.508706Z [email protected] <0.5189.0> d370ff66e9 Uncaught error in HTTP request: {error,undef}
[info] 2020-01-29T20:33:31.508780Z [email protected] <0.5189.0> d370ff66e9 Stacktrace: [{remote,send,[<<31,139,8,0,0,0,0,0,0,19,171,86,170,80,178,82,80,170,84,170,5,0,168,106,142,218,10,0,0,0>>,{remote,<0.51
89.0>,#Ref<0.4172828015.2846359553.182897>}],[]},{couch_httpd,send,2,[]},{couch_stream,foldl_md5,2,[{file,"src/couch_stream.erl"},{line,132}]},{couch_bt_engine_stream,foldl,3,[{file,"src/couch_bt_engine_st
ream.erl"},{line,37}]},{couch_stream,foldl,4,[{file,"src/couch_stream.erl"},{line,102}]},{couch_httpd_db,do_db_req,2,[{file,"src/couch_httpd_db.erl"},{line,255}]},{couch_httpd,handle_request_int,5,[{file,"
src/couch_httpd.erl"},{line,333}]},{rpc,local_call,3,[{file,"rpc.erl"},{line,321}]}]

We might have to add a clause somewhere to accept an attachment parser Pid and read from that or maybe there is more general stream handling error via the RPC mechanism

[wohali]

@nickva For posterity, as I said on IRC, this endpoint is only to support what we need for admin purposes. Right now that's inspecting the top-level of a shard, as well the system databases. I'd like to add support for looking at view shard _info objects, but it's not a 3.0 blocker.

What I'll do is see if we can just return an error when trying to retrieve attachments via this interface, rather than trying to support them for unknown purposes.

Tomorrow.

[nickva]

@wohali pushed a fix, it turned out not as bad as I suspected

http  $DB/_node/_local/shards%2f80000000-ffffffff%2fdeebee.1580329759/dok2/att1

{
    "x": "y"
}

[wohali]

Going to hold this for another 1-2 days to see if I can't get in the ability to inspect specific view shards, not just the view shard that hosts the ddoc itself. If I can't manage that, I'll merge this as is.

[wohali]

Big thanks to @kocolosk who nudged me in the right direction on IRC for per-view-shard endpoint exposure. Like @nickva 's change, it turned out to be very little code to support this.

[nickva]

+1