CID mime type after recursive directory addition to cluster


I am using ipfs-cluster-ctl from Linux to add a directory recursively.

The directory contains multiple PDFs, when I attempt to access any of those with a /ipfs/CID url there is no content-type and browsers just offer to save it instead of using the PDF viewer.

Is there anything I can do for the content-type of the files not to be lost in this process?

1 Like

I can also notice that the same workflow has a different outcome with Image files. I am not sure why, but their CIDs carry media information.

1 Like

Hmm I would have expected PDFs to work fine. The way gateways determine the mime is “magic” I believe, which can behave unexpectedly. The related code appears to be here. It looks like you’d need to access them like /ipfs/CID/1.pdf so it knows they’re actually PDFs (and passes the correct mime to the browser). It’s possible specifying ?filename=1.pdf for example to the tail of the URL would solve it too, but that’s not obvious to me from the code.

Yes, I have continued to investigate. And there is something in the PDF itself that causes this condition.

I can get other PDFs to work just fine. I am using the docker image vladgolubev/libreoffice-pdf-cli for PDF generation from libreoffice documnets, but for some reason other PDFs work just fine.

Thanks for the URL tip, makes it works and also the browser PDF viewer infers the file name for saving.

1 Like