#866 closed defect (duplicate)

HTML-formatted exceptions shouldn't be output by CLI commands

Reported by: davidsarah Owned by:
Priority: major Milestone: 1.6.0
Component: code-frontend-cli Version: 1.5.0
Keywords: usability error Cc:
Launchpad Bug:


Brian wrote in http://allmydata.org/pipermail/tahoe-dev/2009-December/003361.html :

I'm starting to think that a switch to replace every single webapi

exception with a plain-text exception (instead of the HTMLized traceback, with locals and color-coded styles and whatnot) would be a good idea. I see exceptions far more frequently from the CLI tools than from a web browser, and readable-but-less-information would be preferable to sometimes-more-information-but-sometimes-unreadable.

Change History (7)

comment:1 in reply to: ↑ description Changed at 2009-12-21T13:29:38Z by kpreid

Don't invent a special parameter to do this, use the protocol that already exists: the Accept header in HTTP.

comment:2 Changed at 2009-12-21T19:08:18Z by davidsarah

The Accept header specifies acceptable Content-Types for the response, so it's not possible to use it to specify only the Content-Type of error messages. (See RFC 2616 section 14.1.)

comment:3 Changed at 2009-12-22T00:36:09Z by kpreid

But does the command-line client ever want HTML? I suppose in the case where it's fetching a file which happens to be HTML. But since Tahoe files don't have variants, we can Accept: text/plain, */*;q=0.5. Or is there a case I'm missing where we need to express a preference for HTML over plain text?

comment:4 Changed at 2009-12-22T04:38:31Z by warner

Hm, it'd be nice if there were some form of the Accept header that could mean "for regular non-error content, I accept X, but for error messages, I accept Y".

I guess that a regular GET (as in 'tahoe get FILECAP') is really asking for a literal non-interpreted sequence of bytes, so maybe it'd be appropriate to have that GET use Accept: application/octet-stream or however it's spelled.

And then the rule could be that the error code would only produce an HTMLized exception if it looks like text/html would match the Accept header. Browsers will send */* and will get HTML exceptions, the CLI tools will send application/octet-stream and get plain text exceptions.

comment:5 Changed at 2010-01-16T01:15:09Z by davidsarah

  • Keywords error added

comment:6 Changed at 2010-02-01T19:49:15Z by davidsarah

Is this not already fixed?

comment:7 Changed at 2010-02-06T18:28:15Z by davidsarah

  • Milestone changed from undecided to 1.6.0
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #646.

Note: See TracTickets for help on using tickets.