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

[davidsarah]

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.

[kpreid]

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

[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.)

[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?

[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.

[davidsarah]

Is this not already fixed?

[davidsarah]

Duplicate of #646.