tahoe get on DIR2 URIs fails with error message that is too terse

[gdt]

When doing 'tahoe get' and giving a directory URI, I get "302 Found" instead of the bits. Changing DIR2 to SSK gets me bits. There's no good reason not to return the directory contents; 'cat .' on at least BSD shows the bits in the directory. While most people don't want to look ever, and the rest only want to look once in a while, being able to understand directories is key to a deep understanding of how access control works.

Further, the writecaps should be decrypted when the directory is fetched with a writecap.

[davidsarah]

I don't think that BSD cat showing the bits is a good argument for tahoe get (or the corresponding web-API request) to do so. Conceptually, the SSK URI refers to the bits, and the DIR2 URI refers to the directory interpretation. In Unix the same pathname is used to refer to both. So it makes sense that in Tahoe, a command that fetches file contents would succeed for the SSK URI and fail for the DIR2 URI.

Since you can see the bits by using the SSK URI, there's no loss of functionality in the current behaviour. So I'm inclined to "wontfix" this.

Further, the writecaps should be decrypted when the directory is fetched with a writecap.

I completely disagree; that would be effectively creating a new directory format that is not the stored format, which seems overcomplicated and unlikely to lead to better understanding.

[davidsarah]

Reopening to fix the error message, which is just:

Error during GET: 302 Found