incorrect content-type for tarfile from /api/v0/get

[DeedleFake]

As noted in #7746 (comment), the response to /api/v0/get?arg=/path/to/a/directory correctly results in a tarfile, but with the wrong Content-Type, making this a bit of a pain to use as a link to send someone who isn't using IPFS to share a directory with them as it just displays junk info into their browser. This is true regardless of the settings of the archive and compress options.

While I'd prefer direct support in the gateway for sharing purposes, this should probably also be fixed, and would certainly work as a stopgap until that support can be added.

[lidel]

I don't think we want to touch /api/v0, fixing things like this is not a good investment of dev time.

The proper fix here is to add support for ?format=tar on regular gateway (/ipfs/{cid}/path/to/a/directory?format=tar), and ensure that has proper Content-type set.

Rationale: /api/v0 is RPC-over-HTTP and has a long list of requests like this (eg. return proper 404 instead of 500), which we did not do on purpose, because this API v0 is not meant to follow HTTP semantics.
Instead, we should invest in making /ipfs/ and /ipns/ more useful, which will incentivize people to move away from /api/v0 for common use cases.

[DeedleFake]

@lidel

The proper fix here is to add support for ?format=tar on regular gateway (/ipfs/{cid}/path/to/a/directory?format=tar), and ensure that has proper Content-type set.

That's what the referenced #7746 is for, actually.

[lidel]

sgtm. Closing this one, as we closed #6746 before. see #8234 for potential way of addressing #7746