Opening PDF attachment on browser, got content type "binary/octet-stream"

[spaceman]

Previously I have added PDF attachment via API call. This was done using presigned S3 url of a PDF and updating table's field with {"url": url, "filename": filename} whereas url has no ".pdf" in but filename bears the form of "xxx.pdf". 

These PDFs can be opened on iphone app through open with browser, where redirection would be opening a pdf. (Content-type GETing the link is application/pdf).

From yesterday, uploads done the same way would get the right pdf file but with header Content-type: binary/octet-stream. On the phone the pdf failed at displaying and tried to download a file instead.

My question is:

i)  has anyone experienced specifying filename with .pdf now but not getting pdf back?

ii) has anyone got a way way to fix this issue?

This change is breaking existing business needs. Please advice at earliest convenience is possible. Many thanks!

[Gingermatti]

I think we are having the same issue, sorry no solution, just adding here for additional visibility.

We are uploading PDFs via Zapier and have 2 bases where we upload PDFs - one base (and zap) is about a year old and one very recent. The older one has no issues and continues to work as expected - Zapier uploads the PDF, you click on the thumbnail of the file, it opens up the preview window, shows the PDF and if you click download, it downloads as a PDF. So far so great.

The more recent one has the issues described by Spaceman above. Zapier uploads, you can see the thumbnail of the PDF, but when you click it, it launches a blank preview window, and auto downloads a "file", which on inspection is octet-stream. If you click the download button in the preview window, it actually downloads the PDF which works. 

These two bases are exactly the same, the zaps uploading the PDFs are exactly the same, there is no difference between the two, yet one works and one doesn't. We have been through both with a fine tooth comb, no difference. 

There is a known issue regarding retaining file names of files uploaded to attachment fields via API (they typically don't), so we run a script in automations when a file is uploaded to an attachment field, which renames the file to something better for us. Even renaming and adding a .pdf extension doesn't change the behavior in the new base. In the script logs I can see the application type of the source file is pdf, so have no idea why it is behaving like this. 

Apologies Spaceman if I've hijacked your thread with something unrelated, it seems to be a similar issue to me.