tahoe-lafs/trac-2024-07-25

CLI should report webapi errors better #646

New issue

Closed

opened 2009-02-26 19:22:24 +00:00 by warner · 1 comment

warner commented

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

Owner

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.

tahoe-lafs added the

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

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

warner commented

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

Author

Owner

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.

tahoe-lafs added the

fixed

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

tahoe-lafs modified the milestone from undecided to 1.6.0

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

warner closed this issue

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