There are some old questions regarding this topic, but the issue I'm facing is just some days old so thought to create a new thread.
I am using the content-disposition inline combined with filename to open a PDF file directly in Browser.
content-disposition: inline; filename="MyFile.pdf"
Until a couple of days ago it was working fine in Chrome and Firefox, (I know that in old IE versions the filename parameter wouldn't work in inline), PDF was opening in browser with the correct (provided) filename.
Now it seems like the filename parameter isn't working anymore even for Chrome and Firefox. The PDF is opened correctly but created with a name from the last part of the URL, which in my case is just pdf (https://.../pdf).
If I switch to attachment instead of inline the filename works fine, file gets downloaded with the correct filename. Issue is that I need to open the file in browser and not download it.
Is inline with filename not anymore possible in Chrome and Firefox?
I am facing very similar problem lately.
Strangely, when making a POST request for PDF document, the filename is ignored. But if I make a GET request, everything works like before. PDF is shown correctly and SaveAs also works with correct filename.
I ended up making a redirect on the server side, so the last request is a GET.
Another thing I noticed is, when the user clicks on the Download (Save As) button in the browser's PDF viewer, the server gets another request for the document and serves the content again. The Print command however does not make another request and prints the content already in the PDF viewer.
Hope this info helps, even if only to let you know, you're not the only one with this problem.
Edit:
It turned out, that POST and GET requests did not have anything to do with the problem. The problem was Cache-Control: no-store header that prevented the browser to store the PDF content and forced it to make another request for the PDF content at Save As command. The POST command was not formed correctly the second time which resulted in "Network Error".
I removed no-store from the header and now everything works fine.
The new header looks like this:
Cache-Control: no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
I have found that in my environment, URLs containing basic authentication do not allow inline display of pdfs.
Related
We have a pdf preview option in our company's internal back office application. At some point in the past few months or weeks, it stopped working properly in Chrome. The file comes with a header: Content-Disposition: inline; filename="foo.pdf". But instead of displaying in the embed or object tag, it downloads immediately to the configured Chrome downloads folder. This does not happen in, say, Safari, where it continues to display correctly. I can probably find some workaround, like fetching it, converting to base64, yada yada, but I'd like not to have to do that!
I have a statically generated website with GatsbyJS. It uses react-intl for a localization but I don't think this is causing a problem.
When I open the website (it is hosted on AWS S3) for the first time it usually displays german transcription very well, but when I open developer tools and refresh the page the transcriptions are often broken (the specific German letters are not displayed properly).
Transcriptions are stored in a js file.
Steps that I use to reproduce the error:
I reopen the browser and go to the website. If I see correct texts I then open the dev tools and go to Application => Frames section => Scripts dropdown and I see:
Then I refresh the page (sometimes more than once) and somehow texts are now broken:
Note that this is the same static file!
It seems that this is only appearing in Chrome.
When I build and run website locally then it seems to always work (which then would suggest it's not chrome fault).
Not sure where might be the problem
It turned out that javascript files didn’t have charset set in Content-type header in a response. Locally they had:
Content-Type: javascript; charset=utf-8;
And it worked fine but when they get uploaded to AWS S3 the charset field has been stripped out leaving only:
Content-Type: javascript;
Chrome seems to be more restrictive about it.
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
I have an anchor tag that is used to request the download of a file.
Like this:
Download
The file may be modified on the server very often, so I want to make sure the browser does not cache the file.
However, testers found out that, although it seems to always download the file when you click on the link, when you right-click on the link and choose "Save As...", the browser seems to choose to use the cached file instead. This was tested with IE9.
How can I force the browser (especially IE9) to always download the file in every case?
I'll add as an answer. Try adding a random number to the query part of the href:
?param=[random]
As per my own comment for one of the answers:
According to wikipedia I can set the response header parameter: Cache-Control: no-cache
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Effects_of_selected_HTTP_header_fields
After receiving a response with this header, the browser will not cache this data anymore.
How do you make an MP3 link download instead of play "in-browser"?
I tried changing the target to blank, but that just opened the player in a new window.
You can't do this by modifying the link. You will have to have the HTTP server that serves the file send a Content-Type of "application/octet-stream". Presumably it is sending the type "audio/mpeg", which is hinting to the browser that it is MP3 content. Without the capacity to alter this header, you can't achieve this.
If your server supports PHP, create a PHP script called "getfile.php" (or similar) that takes a parameter of a file ID or file name. Set the content-type and content-disposition headers within the script to force a download prompt.
See: http://webdesign.about.com/od/php/ht/force_download.htm
Lots of solutions here. Here's the basic idea:
Use Javascript to make a (ajax) request to the server
When the request is received, run a script
This script redirects your browser temporarily to a new page
The new page has a few headers telling your browser to expect a file attachment, and what kind of attachment it is
The "save as" dialog pops up and your original page is still onscreen
I could be wrong, but I've seen people with the same problem before just with other file types, they used the code below:
<FilesMatch "\.(?i:mp3)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
Hope this works for you!
For quite some time (Chrome 14+, Firefox 20+, Edge 44+) it is possible to use the download attribute on same-origin links to force download behavior even when the server doesn't supply a Content-Disposition header on the link target.
Without access to the server generating the HTTP responses, the browser gets to decide what to do with different types of responses. usually the only files a browser will download are things like .zip files which it cannot display.