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

New Issue

tahoe-lafs · 2009-12-20T21:56:11Z

davidsarah commented

2009-12-20 21:56:11 +00:00

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.

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.

tahoe-lafs added the

labels 2009-12-20 21:56:11 +00:00

tahoe-lafs added this to the undecided milestone 2009-12-20 21:56:11 +00:00

kpreid commented

2009-12-21 13:29:38 +00:00

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

davidsarah commented

2009-12-21 19:08:18 +00:00

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

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 commented

2009-12-22 00:36:09 +00:00

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?

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 commented

2009-12-22 04:38:31 +00:00

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.

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 commented

2010-02-01 19:49:15 +00:00

Is this not already fixed?

davidsarah commented

2010-02-06 18:28:15 +00:00

Duplicate of #646.

tahoe-lafs added the

duplicate

label 2010-02-06 18:28:15 +00:00

tahoe-lafs modified the milestone from undecided to 1.6.0

2010-02-06 18:28:15 +00:00

tahoe-lafs closed this issue