As a first step in debugging this:
1. Use the browser developer tools panel to see what the "Content-Type" header is set to when the file is served from AEM versus other sites where you see it working.
2. What URL are you serving the PDF from? To help you be able to capture the network request in the browser do the following:
a. Open chrome://settings/content/pdfDocuments in the Chrome browser and enable this feature to make it download the pdf instead of opening it.
b. Open a new browser tab and open developer tools then copy / paste the PDF document URL.
c. See what Content-Type header value and other headers you get back. This will help you debug the cause.
Thanks for your suggestions.
Per #1 above, I do see a slight difference between the site that works, and doesnt.
The site that does work has a Response Header : "content-type: application/pdf" value in Dev tools
The site that doesnt work has a Response Header : "Content-Type: [Content-Type: application/pdf ]" value.
I'll have to look into why the key and value are both different (case sensitivity and the extra Content-Type as part of the value)
Per #2 above
For the broken one, I am serving the PDF from the publisher. (the pdf content resides in the dam)
I was able to download the file after changing chrome settings - however, the Response Header had the same value:
Content-Type: [Content-Type: application/pdf ]" So this just confused me more....