#646 closed defect (fixed)
CLI should report webapi errors better
Reported by: | warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.6.0 |
Component: | code-frontend-cli | Version: | 1.3.0 |
Keywords: | web news-done | Cc: | |
Launchpad Bug: |
Description
Most of the filesystem-manipulating CLI tools display some frustratingly useless error messages when something goes wrong. They all use the webapi to contact the node, and the default webapi/Nevow exception-handling response is to return an HTML representation of the exception traceback (for use in a browser), as well as a 500 Internal Server Error. The CLI tools, when they see 500, just dump the HTTP response body to stderr.
One tool that might help fix this is to identify the most likely sorts of exceptions (NotEnoughSharesError, UnrecoverableFileError) and map them into HTTP error codes. There is already some code to do this, in web/common.py, but we could add more error types, and add tests to make sure that we actually catch the errors in the right places.
Another tool that might help would be an extra flag (perhaps a request header, like Accepts:) that tells the webapi server that we (a CLI client, not a browser) want plain text tracebacks instead of HTML. This would at least reduce the pages of impenetrable HTML on stderr to a dozen lines of python stack trace.
Change History (2)
comment:1 Changed at 2009-12-27T20:19:40Z by warner
- Milestone changed from undecided to 1.6.0
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed at 2010-02-02T05:52:13Z by davidsarah
- Keywords news-done added
Fixed (finally). The webapi has been listening to the Accept: header since tahoe-1.4.0, but the CLI tools were not setting one, which RFC2616 says must be treated the same as "Accept: */*" (so HTML traceback). With 2e0a61a9539515fa, the CLI tools all send "Accept: text/plain, application/octet-stream", which will cause the webapi to give them text/plain tracebacks.
Many specific exception types are mapped into more useful messages, in source:src/allmydata/web/common.py (humanize_failure()). This helps too.