issue_comments

Also weird: errors returned by that mechanism look like this: json { "ok": false, "errors": ["list of error messages"] } While errors returned by the rest of Datasette look like this: https://latest.datasette.io/fixtures/no_table.json

json { "ok": false, "error": "Table not found: no_table", "status": 404, "title": null } Related: - #1875

Looks like the code I've written for permission checking on TableCreateView and friends doesn't use the regular raise Forbidden or raise DatasetteError mechanisms - it does its own thing here:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/views/database.py#L580-L584

Which uses this:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/views/base.py#L547-L548

Having two different patterns to return errors is bad, I should fix that.

Easiest fix would be to look for accept: application/json and/or content-type: application/json headers.

Not bullet-proof, so people might occasionally make JSON requests and get back an HTML error - but the documentation can tell people that they need to send those headers if they want to reliably get back JSON error messages.

I'm happy with this as a solution.

Sniffing for a { is a little bit tricky though, as the post body is lazily loaded on request here:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/utils/asgi.py#L127-L135

This raises a more complicated issue

At some point I'm likely to want to add an HTML interface for creating tables and inserting and updating rows.

The obvious URLs for that are the same as for the JSON API: /db/table/-/insert and suchlike.

Those endpoints are currently POST only - and can return JSON all the time.

If they start accepting form POSTs too they'll need to be able to accept form-encoded data and return HTML instead. That's OK - they can detect incoming JSON thanks to the content-type header an the fact that the request body starts with { - but the should_return_json fix described above could intefere with how errors are returned if I'm not careful.

I think it can still work though: I'll only set should_return_json = True if the endpoint gets a POST with a body starting {, or a content-type JSON header.

I'm going to prototype that up to see what it looks like.

I need a way for those JSON endpoints to communicate back to the handle_exception handler that they are returning JSON, so it knows to behave differently.

Since it gets the request object, one way could be to have view code set request.should_return_json = True so that the handler knows to do something different.

It's a bit of a cludge though!

Most .json errors DO return as JSON, thanks to this:

https://github.com/simonw/datasette/blob/c094dde3ff2bae030f261e6440d4fb082eb860a9/datasette/handle_exception.py#L19-L24

https://github.com/simonw/datasette/blob/c094dde3ff2bae030f261e6440d4fb082eb860a9/datasette/handle_exception.py#L57-L58

But that code triggers when the URL ends with .json - and none of the JSON write API endpoints (things like /db/-/create and /db/table/-/insert) follow that convention.