I have a page which outputs a PDF file to the browser, and sets the following headers:
Content-Type: application/pdf
Content-Disposition: inline; filename="myFile.pdf"
So, the file should be viewed in the browser rather than downloading. This works as expected in Chrome for desktop, except that the "Save" button in the bottom right corner doesn't do anything.
Additionally, when opening on a mobile (where the file is automatically downloaded), the download fails as the file is <Untitled> - despite the presence of filename="myFile.pdf in the headers.
I thought this was a header issue, but have narrowed it down to the fact the page is under HTTPS. If I open the page under HTTP then everything works as expected (files saved successfully) on both desktop and mobile.
So, is there any way to get this working under HTTPS?
It seems that this issue is due to the SSL certificate under which the website is hosted being invalid.
See more here - Android 2.2 and 2.3 PDF download via HTTPS seems broken
Related
Trigger a file download:
https://alwaysepst.blob.core.windows.net/ulm-my/Projects/UnileverMT/CompetitorReport/201901/AeonBigAmpangOverdue11days_20190111T170348680.jpg
Opens a webpage:
http://personal.psu.edu/xqz5228/jpg.jpg
The server that the first url points to returns a header Content-Type: application/octet-stream which tells the browser to trigger a file download whereas the second url has a header Content-Type: image/jpeg which the browser is able to interpret by itself as an image file.
If you were trying to create this behaviour, the first example isn't really an accepted way of triggering a download. See this answer for more details on that.
There's also a download attribute for the a element in html. See here.
Using Firefox 45.8.0 ESR on Windows.
Trying to load https://secure.scheduleonce.com/dana
The page doesn't load, and in the network panel I see a crossed padlock icon instead of green padlock icon for this request:
OPTIONS https://cfproxy.scheduleonce.com/get-data/GetLandingPageLayout
When floating over the padlock I see the following message:
The connection used to fetch this request was not secure.
The page loads fine on Chrome / Safari / IE and even more recent version of FF.
Is there any way to debug what's wrong with that request to resource exactly ? FF doesn't give me any information as to what went wrong.
I suspect it might be related to the fact it's a preflight CORS request (the requested domain is different than that hosted page domain).
Attaching HAR file of the network : https://www.dropbox.com/s/i59k66a2w8p3ast/Archive%2017-09-10%2007-06-15.har?dl=0
Can be viewer here: (https://toolbox.googleapps.com/apps/har_analyzer)
Thanks.
Problem was with the cipher suite choice on the server.
I used this site to change it:
https://mozilla.github.io/server-side-tls/ssl-config-generator/
To support older browsers as well.
I don't know what was in FF 45.8.0 ESR that made it not respect the security of the server.
I am helping migrate a legacy application. One of the requirements is we are able to handle requests for old images.
What we have is:
New site on new.com
Old site on old.com
Images to links (imported content) point to /imgs/cat.png however the actual image is hosted on old.com/assets/images/cat.png (for now).
<img src="/imgs/cat.png"/>
I setup a redirect for all png, jpg, jpeg, gif that 302's requests for new.com/imgs/(.*).(png|jpg|jpeg|gif) to http://old.com/assets/images/$1.$2
Everything works find in Chrome, Firefox and IE9 - however it was noted in IE8 the image does not render. Its possible that it has the same issue in IE7, 6 and 5.5 however I have not been able to test this.
Does anyone know why this is happening and how to fix?
I tried setting the contentType header on the response of the 302's to image/(png|jpg|jpeg|gif) and this did not have any impact.
Any insight would be appreciated.
Turns out the host that the images were served from was not a Trusted Site in IE, where as the host that served the page was. Normally youd see a popup asking if you wanted to accept an untrusted resource, however because this was a 302 redirect (original img URL was to the trusted, but 302'd to untrusted) IE never showed the popup.
I've encountered a strange bug in Chrome 19. I implemented a full-AJAX website (every non-external link is opened via AJAX request) with pushState support. I transmit the HTML snippets in AJAX via JSON format.
When I leave my site via an external link and then go back, Chrome renders cached data for that URL - the problem is, he caches the JSON content and shows that, instead of full web-page.
This is reproducible by these steps (UPDATE: I removed AJAX functionality on my website since then, so this bug does no longer appear):
Open http://beta.mirtes.cz/
Click on the second date link (16. 6. 2012 next to "It all began with a strange e-mail"). This page (you are now at http://beta.mirtes.cz/it-all-began-with-a-strange-e-mail) is loaded via AJAX.
Click on "It all began with a strange e-mail". You are redirected to an external website.
Click "Back" in Chrome after the page is completely loaded.
I try to send all AJAX responses with Cache-Control: no-cache, but with no effect.
Firefox 12 works OK.
I came with a workaround - I perform AJAX request with additional dummy GET parameter - ?ajax=1. This way the browser can recognize the difference between usual HTML content and JSON. It doesn't have any impact on the user, the parameter is visible only in Firebug.
So this is the error message I see on product pages next to the like button.
There were problems uploading
"http://www.palmercash.com/images/xxxxxxx.jpg" on behalf of your Open
Graph page. Here is the full error message our photo server reported:
"Error Processing File: Unable to process this photo. Please check
your photo's format and try again. We support these photo formats:
JPG, GIF, PNG, and TIFF."
The like button works fine, but the image doesn't show on facebook even though it is a correct URL.
I've done the linter and I just have a warning about og:url
but I've looked at other websites using the exact same code and the photos show fine.
Here is an example URL
http://www.palmercash.com/p-4440-mens-the-onion-mlk-t-shirt.aspx
I have checked the iis 6.0 logs and it appears facebook bots come and pull the images fine, as there is no error message there. I'm just wondering what could cause this to happen. I'm at a lose right now.
This is because image you using as og:image is always returned by your server as gzip compressed without respecting Accept-Encoding HTTP header (even if Accept-Encoding: identity header passed with request your server still uses result in Content-Encoding: gzip and using compression).
Facebook's crawler probably doesn't pass this header and try to use this as image directly without decompressing it first.