Unable to list or fetch bucket

[ErikBjare]

Trying to access the following URLs from my browser:

http://localhost:5667/api/0/buckets/
http://localhost:5667/api/0/buckets/aw-watcher-window_erb-laptop2-arch
http://localhost:5667/api/0/buckets/aw-watcher-window_erb-laptop2-arch/events

Gives me {"reason":"Resource was not found.","status":"error"} even though the bucket should exists (watcher is reporting, and bucket is listed at startup).

I also checked http://localhost:5667/api/0/info and it works fine (testing is incorrectly always set to false though).

(I've changed the development port to 5667 to not collide with aw-server testing, but otherwise I haven't changed anything.)

[johan-bjareholt]

Hm, that's odd.

Seems wierd that you don't even get 200 from http://localhost:5667/api/0/buckets/

When you start aw-server-rust you will see which paths are mounted, start with pasting that here so we can investigate.

I also checked http://localhost:5667/api/0/info and it works fine (testing is incorrectly always set to false though).

Yeah this is hardcoded if I remember correctly, I'll add a issue for that

[ErikBjare]

Output looks fine, can't figure out what's wrong...

    Blocking waiting for file lock on build directory
   Compiling aw_server v0.1.0 (/home/erb/Programming/activitywatch/other/aw-server-rust)
    Finished dev [unoptimized + debuginfo] target(s) in 6.06s
     Running `target/debug/aw_server`
Bucket { bid: Some(1), id: "aw-watcher-window_erb-laptop2-arch", _type: "currentwindow", client: "aw-watcher-window", hostname: "erb-laptop2-arch", created: Some(2018-11-23T17:26:30.377319030Z), events: None }
🔧  Configured for development.
    => address: localhost
    => port: 5667
    => log: normal
    => workers: 8
Bucket { bid: Some(2), id: "aw-watcher-afk_erb-laptop2-arch", _type: "afkstatus", client: "aw-watcher-afk", hostname: "erb-laptop2-arch", created: Some(2018-11-23T17:27:20.684495108Z), events: None }
    => secret key: generated
    => limits: forms = 32KiB, json* = 1000000000B
    => tls: disabled
🛰  Mounting '':
    => GET /
    => GET /favicon.ico
    => GET /static/<file..>
    => GET /0.css
    => GET /0.css.map
🛰  Mounting '/api/0/info':
    => GET /api/0/info
🛰  Mounting '/api/0/buckets':
    => POST /api/0/buckets/<bucket_id> application/json
    => DELETE /api/0/buckets/<bucket_id>
    => GET /api/0/buckets application/json
    => GET /api/0/buckets/<bucket_id> application/json
    => GET /api/0/buckets/<bucket_id>/events?<constraints> application/json
    => POST /api/0/buckets/<bucket_id>/events application/json
    => POST /api/0/buckets/<bucket_id>/heartbeat?<constraints> application/json
    => GET /api/0/buckets/<bucket_id>/events/count application/json
🛰  Mounting '/api/0/query':
    => POST /api/0/query application/json
🛰  Mounting '/api/0/import':
    => POST /api/0/import application/json
👾  Catchers:
    => 404
🚀  Rocket has launched from http://localhost:5667

Edit: Ran with debug logs, found this:

GET /api/0/buckets text/html:
    => Routing the request: GET /api/0/buckets text/html
    => All matches: []
    => Error: No matching routes for GET /api/0/buckets text/html.
    => Warning: Responding with 404 Not Found catcher.

Apparently using the text/html mimetype will fail the routing. If you want to return any error code at all, you should return 406 Not Acceptable but it'd be preferred if it just didn't care and sent JSON anyway (like aw-server-python does).

[johan-bjareholt]

Apparently using the text/html mimetype will fail the routing. If you want to return any error code at all, you should return 406 Not Acceptable but it'd be preferred if it just didn't care and sent JSON anyway (like aw-server-python does).

No, if you request text/html you should not respond with application/json, that simply doesn't make sense. I agree that a 406 would make more sense though since the client/server fails to negotiate what content type is requested.

[ErikBjare]

You can request text/html and still get application/json back. The Accept header is not about strict negotiation, it's about preference (as the Rocket docs themselves state).

See how other APIs do it, like GitHub. If you browse to one of their API endpoints you will get JSON back despite your browser preferring text/html in the Accept header.

Throwing a 406 is almost never done in practice for this reason (as suggested in the MDN docs). It just means one more header you need to set in your request, even when there's only one content type you expect.

[johan-bjareholt]

Where can I find this in the Rocket docs? The only related section I can find is https://rocket.rs/v0.4/guide/requests/#format

If you want to prefer text/html but want to allow anything you should set your accept header to text/html,*/*;q=0.1

Also, my Accept header in both Firefox and Chrome set */* so it should still work without the patch
Firefox: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Chrome: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

[ErikBjare]

I was just saying that the Rocket docs use the terminology "preference" for the Accept header, not negotiation (and does not have strict enforcement by default).

Regarding */* I saw that as well, but Rocket doesn't seem to respect it. Further reason to just merge my patch.

[johan-bjareholt]

Regarding / I saw that as well, but Rocket doesn't seem to respect it. Further reason to just merge my patch.

There's a test for it though which is odd.
https://github.com/SergioBenitez/Rocket/blob/master/core/http/src/accept.rs#L418

My opinion is that the industry standard of not caring about the Accept header is stupid, but since Rocket responds with a 404 rather than a 406 the error unclear to people who want to use the REST API so I guess I have to just accept this and move on. Merging.