We have a rails application that serves up PDFs to users via send_file
We are getting complaints that when the user opens multiple PDFs in a given day, when they click on our link, adobe opens the PDF they read last time.
We have looked at our logs / audits and everything appears that the correct data was sent to the user's browser.
We are unable to reproduce this problem, and we are only getting 1 or 2 out of thousands of users that are running into this issue.
The only workaround right now is for the user to close all instances of Firefox.
Anyone ever seen anything like this before?
It sounds like a caching issue to me.
I add this to the headers of the PDF's my web applications serve:
format.pdf do
response.headers['Accept-Ranges'] = 'none'
response.headers['Cache-Control'] = 'private, max-age=0, must-revalidate'
response.headers['Pragma'] = 'public'
response.headers['Expires'] = '0'
render
end
I added these headers to solve issues serving Internet Explorer clients over SSL and there may be more in there than you need, but it looks like it could solve your issue, too.
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I have been fiddling with rails apps for a while and I sometimes see this behavior on Safari (could be on other browsers as well, not sure) where the browser downloads the response as a file instead of rendering it in the browser. I wonder why that is.
The last time it happened made me decide to ask on stack overflow. My current setup is a very basic rails app that implements devise and I get a file named 'sign_in.admin' with just the following content:
You need to sign in or sign up before continuing.
I know that string comes from the devise locale and is supposed to be rendered with a layout, but the browser just downloads it as a file as if I chose to 'Download linked file as...' It's happened to me before where instead of rails routing me somewhere it downloads a file. Can somebody explain why my browser sometimes does that? I have all the latest updates.
I'm making some fanpages.
I have a code that show an image to the user before liking the page, and another image or content after liking the page.
I created several pages with this code and all of them worked fine.
but about 5 days ago, I created one with the same code, and it just showed the "after like" content, even when I haven't liked the page.
and today, I created a new one, and it just shows a blank page. neither the after or the before.
I've checked on the previous fanpages and those are still working, so it's just the new pages that aren't working.
they'r using the facebook php sdk
the procedure I use is:
* upload files to my server
* create a new app
* add urls for page tab (both normal and secure url)
* add app to my page
is someone having the same issue?
does someone know why is that problem and how it can be solved?
thanks,
Abraham
if you have php errors turned off, and you throw a fatal php error before any html output, you might also see a blank screen.
Try uploading a dummy file with some simple text as your main app page, and see if it works.
If so, try tracking down any error that might prevent the page from rendering.
To get output on php errors, add this to the top of your page:
<?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
?>
I'm making a website where a user can say which items he wants to cache. Based on this, a manifest file is generated. By doing this the user can still browse in the website when he is offline. This is all working fine in google chrome. But on iPad it's not working as it should.
Sometimes things get cached sometimes not, not even the pages i visited.
We have been testing with 2 iPads all morning, but we haven't been able to get the same result on both iPads. Even if we do exactly the same, we sometimes get different results.
So what we do:
turn WiFi on
browse to the website
make some settings so some pages/images/... are added to the manifest file
turn WiFi off
go back to safari refresh/browse to pages that should be cached.
Sometimes on one iPad (this is an iPad 1) it works exactly as it should, but sometimes it doesn't work at all.
On the other iPad (this is an iPad 2) it never works completely as it should. Just some random results.
It also looks like the results are different when we completely shutdown safari, and then clear the cache and then do the whole process of downloading and caching stuff...
Somebody can help me with this problem? It's a real pain in the ass at the moment... :(
Open web server (IIS)
Select website
Open MIME type
Add or edit to text/cache-manifest
Reset iis at command prompt iisreset
It works for me.
I've encountered some problems as well with ipad caching.
MIME type of the manifest file is not set right due to windows hosting. The standard MIME type on a windows server is "application/x-ms-manifest". This was created when the ClickOnce applications came to life. The MIME type that is necessary to work on safari is: "text/cache-manifest"
Cache size is too small on ipad (you should get a warning to enlarge it)
the Ipad needs time! I've noticed that the cache is not filled when you see all assets or when the website is "loaded". Give it twice the normal time to load before you place the website to your homescreen.
Cache of the cache :) The iPad only reloads the files when the modified date on the server is changed. So when you really want to test, clear all cache on the iPad, remove the link on the homescreen and upload all your files again.
Conclusion: Time consuming!
Hint: Turn on the debug console in safari on your desktop or iPad. It gives a fair idea if you did something wrong or if it is a cache problem on the iPad.
It looks like the problem didn't have anything to do with the application cache. It was somehow a problem with the cookies/the way i was dynamically building the manifest file.
I'd like to slightly echo Pieter-Paulus Vertongen, I had a similar experience with Windows hosting.
According to the debugging console in Safari, the mime type for the manifest file was being misread and nothing was being downloaded as a result.
I copied all of my files, including the .htaccess file, over to a linux server without changing any content within the files...and then the caching worked beautifully.
So yes, it's possible this may be an issue of where the files are hosted. Use the debugging console and Jonathan Stark's code to find out:
http://jonathanstark.com/blog/debugging-html-5-offline-application-cache?filename=2009/09/27/debugging-html-5-offline-application-cache/
We have a Web application (ASP.NET) which displays in some page links to miscellaneous Office documents.
The links are not to web files but rather to a web page which dynamically loads the content form a network folder then sends it to the browser by appropriately setting the mime type.
Everything works fine when testing with desktop browsers (a.k.a. the browser proposes the right application to open the file and the file is successfully opened).
When testing with a Blackberry (Bold 9000) the built-in browser raises an error message stating the selected item (an Excel document) cannot be displayed.
The odd thing is Excel files attached to mail messages can be opened on the same device (via Documents To Go I think).
Anybody has an idea why the Excel attachment could be opened as email attachment but not when downloaded from web? Could this be caused by an incorrect MIME type setting?
Please note that the Blackberry testing was done only by a (remote) user as the BB used for development has an older OS (4.3) which doesn't support Office files anyway. I am not able to actually test with a 4.5+ BB.
Here's the code (excerpts, f is a FileInfo):
Response.Clear();
Response.ClearHeaders();
Response.ClearContent();
Response.AddHeader("Content-Length", f.Length.ToString());
Response.ContentType = "application/excel" // for xls files
Response.AddHeader("Content-Disposition", "inline; filename=" + f.Name);
Response.WriteFile(f.FullName);
Response.Flush();
Response.Close();
Response.End();
I am going to try different mime types as documented on filext.com but, as this is going to take a while because of physical device unavailability, if anybody has a clue I'd be glad to hear about it. I'll keep this posted if I find a solution.
Thanks.
On RIM they say you should use BES to view PDF, DOC etc
I've test it: ASP.NET site with simple < a href ="...">< /a > link to doc file + MDS simulator + 9350 device emulator. Results same as in forum topic:
Socket Channel not able to connect;
address 127.0.0.1:1900
Unfortunately can't test it on BES, but you should try it.
My opinion is BES allows to view office files with DocsToGo opened with simple links.
Actually I was a bit misguided by user's feedback: after further investigating this issue, it came out that only Excel files failed to open, not all Office files.
After changing the MIME type from "application/excel" to "application/**vnd.ms-**excel" it worked fine.