CLI should report webapi errors better #646

New Issue

warner · 2009-02-26T19:22:24Z

warner commented

2009-02-26 19:22:24 +00:00

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.

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.

warner added the

labels 2009-02-26 19:22:24 +00:00

warner added this to the undecided milestone 2009-02-26 19:22:24 +00:00

warner commented

2009-12-27 20:19:40 +00:00

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 changeset: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.

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 changeset: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.