Incorrect `content-type` header returned by Uploadcare converted file

Questions / Help
1

I’m uploading a file (DOCX) to Uploadcare, then sending a convert request to convert the file to a PDF.

When I fetch the converted file with a GET request the content-type header is incorrectly set to application/octet-stream. The file conversion is working correctly (I am able to download the PDF file and open it) but when I try to render it in a WebView (i.e. on iOS via Safari) the document is just rendered as a string of gibberish characters. I believe the WebView is attempting to render the PDF file data as a regular text string.

When I fetch the original file the content-type header is set correctly.

I’ve tried fetching the converted file using the following URL schemas:

  • https://ucarecdn.com/${convertedFileUUID}/
  • https://ucarecdn.com/${originalFileUUID}/document/-/format/pdf/
  • https://ucarecdn.com/${convertedFileUUID}/document/-/format/pdf/ (gives a 404)

Does anybody have any ideas about how I can get the correct content-type header for a converted (PDF) file?

Cross-posting Incorrect `content-type` header returned by Uploadcare converted file - Stack Overflow

2

Hi @Max_Johansen,

Thanks for getting in touch! Actually, this is a known issue, and we’re working to fix it. We’ve recently rolled out a massive update to our core platform codenamed File Lens. It’s a service that deeply analyzes files and can properly determine the file type based on its content, not only the mime type that we receive from the client/server. As a next step, we are going to integrate it with the Document Conversion API so the output files go through the File Lens pipeline as well as regular uploads.

We don’t have an ETA to share yet, but we’ll keep you posted and let you know as soon as we have any updates.