I have my resume linked in my home page.
But I found when I host the pdf file on two different storage server, the default behavior when click on the link differs: one directly download the pdf file bug the other preview in a new tab.
the two links are as below:
http://data-10045577.file.myqcloud.com/doc/Zhao.Kai_ShanghaiUniv.pdf
http://7xocv2.dl1.z0.glb.clouddn.com/doc/Zhao.Kai_ShanghaiUniv.pdf
I have tested on firefox chrome IE that this is not a browser issue.
For some price issue I have to switch to the storage server of which the default behavior is downloading pdf file.
what settings should I have so that click the pdf link then preview instead of downlod?
Additionally, the storage server provide a configure option that can set the "http header", I know little about the web, so can setting a header work, if so, how to ?
I googled it and it seems the content-disposition argument in http header account for this. But I add content-disposition='inline', doesn't help.
if not the browser's issue, then the download one is added programmatically with headers, and the preview one is just putting your file in that folder on the server
Related
I fear this might be a bug with firefox, as this seems to work fine on any other browser I've used. If it is not a bug, what steps need to happen to force a download (versus a display in browser) of a file that can't be displayed in the browser.
Created a react site with a fastapi backend, through the api I am able to attain the url for a file to download.
A standard Anchor element is created for the download, when the user presses a button:
let a = document.createElement('a');
a.href = url;
a.dispatchEvent(new MouseEvent('click'))
but I get a matrix screen of characters rather than a download (only on firefox). I have another file on the same page that is text-based and through the same process get a "save file box" pop-up from firefox.
I've tried, surrounding the above code with
document.body.appendChild(a);
and
document.body.removeChild(a);
as I read that at one time firefox required that.
I've tried using the settings in firefox to force a download e.g. "Save File", but the extension is not listed and I changed all the extensions and the selection for "other files" to "ask whether to open or save files"
On the Anchor Element table of browser compatibility
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a
there is an * for firefox that says "see implementation notes", yet the only notes I see referring to firefox are
If the Content-Disposition header has different information from the download attribute, resulting behavior may differ:
If the header specifies a filename, it takes priority over a filename specified in the download attribute.
If the header specifies a disposition of inline, Chrome and Firefox prioritize the attribute and treat it as a download. Old Firefox versions (before 82) prioritize the header and will display the content inline.
Which I am unsure how to use that information, I have the latest firefox version and the above code works fine on Chrome and other browsers. There doesn't seem to be much information about "specifying a disposition of inline", at least for react.
I can also take the link directly from the api and put it in the different browsers with the same effect (outside of the react/web front end). The only one that tries to open the file is firefox, the rest download it.
Thanks!
There doesn't seem to be much information about "specifying a disposition of inline", at least for react.
The Content-Disposition header is an HTTP header and needs to be set on the HTTP response given by the server.
React has nothing to do with it as it runs on the client.
(And you want to set the disposition to attachment, not inline, since the download attribute isn't working).
but I get a matrix screen of characters rather than a download (only on firefox).
This suggests that:
The download attribute isn't working anywhere (likely because you are making a cross-origin request so the attribute isn't supported).
The content-type of whatever the URL points to is either:
Wrong
Just not recognised by Firefox
… and downloads in other browsers are triggered by them recognising the content-type correctly (i.e. not the download attribute).
The solution is going to involve changing the Content-Type (if it is wrong) and/or Content-Disposition (to specify that the resource is an attachment and so should be downloaded and not displayed inline) of the resource the URL points to.
I'm trying to write MVC endpoint that will optionally set the content-disposition to inline or attachment in order to either display the file (a pdf) inside a new browser tab or else to download it. The UI allows the user to select how they'd like to open the file (not my design - can't change that aspect of it).
Note that this works in Chrome/Edge just as expected.
In Firefox, the application settings for PDF appear to trump the content-disposition. Is there a reliable way to get Firefox to respect the content-disposition? Preferably a way that will work w/ a vanilla installation of the browser such that end-users don't need to make any modifications on their end for it to work.
Here's the code I'm using to setup my response (class is derived from ApiController):
var response = Request.CreateResponse(System.Net.HttpStatusCode.OK);
response.Content = new PushStreamContent((stream, content, context) =>
{
dispatcher.Dispatch(request, stream);
}, new MediaTypeHeaderValue(MediaTypeNames.Application.Pdf));
response.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue(contentDisposition)
{
FileName = $"{auto_generated_fileName}.pdf",
};
response.Headers.CacheControl = new CacheControlHeaderValue()
{
NoCache = true,
NoStore = true
};
return response;
We have noticed this issue in our webapp as well. The webapp has a download button that lets the user download a PDF file. Firefox shows the PDF file in the current tab, which effectively kills the webapp.
After a bit of research, this appears to be an intentional feature, see the release notes for Firefox 98:
When you set an application to open files of a specific type in your Firefox preference settings, those files will open automatically, even files served by the website with "content-disposition: attachment". The same applies to PDF files that are set to open in Firefox by default. This is a fix to bug 453455.
Personally, while I can understand some users may want this for web pages that don't behave well, this is an issue for well-behaved web apps.
Setting the download attribute on the anchor does not appear to work either, Firefox still shows the file inline (tested with Firefox 99.0)
So as far as I am aware, you cannot force the browser to download the file if the browser does not allow it. Other web apps such as OwnCloud or Google Drive are having the same issue -- if you click right on a PDF file in Google Drive and then click on Dowload, Firefox still open the PDF file inline, whereas Chrome downloads it.
For now, it seems the best you can do is to open file in a new tab, to prevent the webapp or web page from being replaced by the downloaded file (which is also what Google Drive seems to be doing). You can open the download in a new tab or window e.g. via the target attribute on an <a> links or via the formtarget atttribute on a <button> element.
I found #blutorange's answer after trying to find a solution to the same problem as OP. However, just before I got here, I stumbled across this answer from back in 2013 - https://stackoverflow.com/a/16515146 which suggests to set the Content-Type header to application/octet-stream, instead of application/pdf.
I tried that solution and what do you know - it works! The PDF opens in a new tab in Firefox automatically, but at least it doesn't replace the tab of my application, so yay! Chrome doesn't seem to mind it either and my PDF viewer on my computer also recognizes the files as PDFs.
Now, this might not be the most "correct" fix to the issue we're facing, but it's an alternative to forcing open a new tab.
I have instructions to give to customers for how to send in har files for debugging SSO issues for all common browsers but Safari. Remote debug is not an option. My current instructions basically say "you can't do this on Safari"; I've seen others say this too.
I found this relatively recent stackoverflow post yesterday that says you can at least make the data persist now:
Safari Developer Tools: Preserve Network Log on Navigation
So now I need to export it. I found this link that gives some instructions, but at the last step, we don't see the 'copy all as HAR' selection.
http://help.catchsoftware.com/display/ET/Collecting+Browser+Performance+Information
Does anyone know how to export the browser network traffic on Safari? Am I missing something?
When you have the "Web inspector" visible in Safari and you're viewing the "Network" tab, the "Export" button at the top right will export a HAR file of the last loaded page.
You can also right click on a single request and click save to a file.
I have set up a webdav folder that I can access thorugh chrome and edit files and save them back to the server, for example, I can open a word doc, edit it and save it back.
When I come to open a pdf, it wont save back to the server and downloads a copy of the pdf instead of the original.
Is there a way of enabling this to edit a pdf?
My end goal is to be able to open a pdf, add comments/highlights and save it back to the server, through my browser.
Thank you
Edit:
I have set this up through Apache 2.4, no plug ins through chrome, I have mapped a network drive to the server folder where I can open and edit files. Except PDFs, I would like to add comments to a off but when I open one the option is greyed out and when I try and save it after opening it tries to save to my desktop.
I'm not sure i've got your use case right, but if i've understood you correctly you have a link in a web page to a PDF which you're viewing in chrome. You click on that link and the PDF downloads to a temp file from which it is opened. If you edit and save those changes are simply saved to the temp file on your local PC. Is that correct?
If so, then this is simply normal behaviour for links in web pages. There is absolutely nothing in the HTML standard which suggests links should be opened by an editor with knowledge of the source location.
What you really want is for the link to launch an editor program which retrieves the remote document in edit mode (probably locking the remote resource) and then have edits saved back to the server. For this to happen there generally needs to be some special interaction in the browser. In Internet Explorer this is provided by the sharepoint dll and special script code. I think there's a plugin for Chrome which does the same thing, although differently.
I havent used the Chrome plugin, but i think this might help - https://code.google.com/p/npapi-msdocs/
I have upgraded a SharePoint, excatly same code, but now links to pdfs always prompt to save and dont open from within the browser (which they do on the old server)
old server is named: localintranet
new server is my local machine: myserver:3200 (yes its on port 3200)
Any ideas?
I did try adding my server to the list of local intranet machines in internet explorer to no avail.
I have tried both href=file.pdf target=_blank and onclick=window.open('file.pdf');return false; in the anchor tag
driving me nuts!
Try to add
AddType application/pdf .pdf
line into your .htaccess file in the http root folder of your web server.
Two things:
to be sure check:
Adobe Reader.
Choose Edit > Preferences.
Select Internet in the list on the left.
Display PDF in Browser should be OK.
probably server sends header for .pdf to download it, instead open inline?
Header set Content-Disposition inline
You gotta love microsoft
http://blog.brainlitter.com/archive/2010/05/19/sharepoint-2010-treats-pdf-and-other-file-types-as-insecure.aspx