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
Related
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.
when i am trying to view files from my TFS document library it's download the file instead of opening it automatic with excel OR word that are already installed on my pc, does someone know how to fix it?
i am using office365 and TFS2015 as you can see at the screenshot that attached this is how it's look like in PC that working fine.
This kind of issue may related to your IE security setting, try to add the related sharepoint site in trust site and try again:
Close your browser (if you don't and you have your SharePoint site up you'll get a bunch of script errors because of the change to access
levels).
Go to your Control Panel
Open Internet Properties
Select the Security tab.
Select Trusted Sites
Click Sites, and add the URL for your SharePoint site.
More details please refer this similar issue: "Some files can harm your computer" dialog when I open a file from the document library
If the warning dialog is disappear, but when you open file still download. Then that behavior maybe defined by your browser. Try some other browser such as IE/Chrome/FireFox. Double check the integration/link of your browser and Word,Excel.
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
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 a site, hosted on Dreamhost, with several pdf files. When I try to open them in Chrome's pdf viewer, the viewer opens but I get a "Failed To Load PDF Document" message or sometimes the view doesn't open at all and I just get a 503 message. On another site that I know to be hosted on Dreamhost I get the same issue. All other content on these sites load fine.
If I use another browser to open with another PDF viewer (Preview or Adobe Reader) the pdfs from my site load fine.
If I try to open pdfs from other sources in Chrome's viewer they work fine.
Is there something I can do on my end to fix this? Is this something likely caused by Dreamhost? Has anybody else had an issue like this?
Although not recommended by Dreamhost, you can resolve this issue by unchecking the "Extra Web Security?" option under "Manage Domains" in the control panel. This feature uses Apache's mod_security to add request filtering and provide security for your site.
If you still want this feature enabled, you will have to add a .htaccess file in the root of your site to bypass some of the filtering. To allow access to a specific pdf, you would need add something like
<IfModule mod_security.c>
SetEnvIfNoCase Request_URI ^/example\.pdf$ MODSEC_ENABLE=Off
</IfModule>
Here's more information on Dreamhost's use of mod_security and writing custom .htaccess rules.