`ipfs get --compress` gives incorrect Header

[RichardLitt]

The headers for curl -i "http://localhost:5001/api/v0/get?arg=QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o&compress=true&compression-level=1" are:

Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output
Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output
Content-Type: text/plain
Server: go-ipfs/0.4.0-dev
Trailer: X-Stream-Error
Transfer-Encoding: chunked
X-Stream-Output: 1
Date: Fri, 19 Feb 2016 13:35:17 GMT
Transfer-Encoding: chunked

The Content-Type should be application/x-gzip; charset=binary, not text/plain.

[whyrusleeping]

This one is probably going to wait until @keks finishes his refactor

[gammazero]

When not using compression, files are returned in a tar format. Should the Content-Type header be application/x-tar in that case?

Related: #6494

[gammazero]

@lidel The real question here is, do we want to make this endpoint into a formal API?

[lidel]

We could clean this up and return correct Content-Type here to improve UX, but not critical:

• While /api/v0/get is how files+directories can be deserialized by third-party applications
• .. the same could be done via ?format=tar on regular gateway, and BETTER because of HTTP Cache-Control and regular HTTP GET instead of HTTP POST which is required by RPC port.
• means, only value add of using /api/v0/get is ability to control compression?
  • perhaps we could fix Content-Type, but also improve ipfs get --help to include guidance that HTTP users should use regular gateways and ?format=tar if they want to fetch more than a flat file.