I am getting one weird issue with IE 8 only. In my app, we have write the binary response to the HttpResponse object and the data content is PDF. We are using third part tool "Tall PDF" to make PDF's. But this whole operation end up in freezing my IE and eventually had to end-task the IE instance..
Following is the code excerpts:-
Response.Clear();
Response.ContentType = "application/pdf";
nb.WritePDF(Response);
Response.Flush();
Response.End();
nb is the class and calling the method WritePDF to write the data to the Response obj. This thing is working fine in IE 7 and other browsers, but for some reason it is giving problem in IE8.
Pls suggest any work arounds or tweaks.
Please try the code snippet provided in the following blog post: Rendering PDF Files to Browser using .NET Code
i found the solution
response.AddHeader("X-UA-Compatible", "IE=EmulateIE7");
Related
All, I am working on an ASP.NET 4.6.1 web forms application that renders pdf documents natively on a browser.I get an error message only on IE 11 when some pdf documents are rendered as shown in the screenshot saying "The file is damaged and could not be repaired.Local\EWH-6624-0".The same document renders fine on Chrome and FireFox.Has anyone encountered the same issue? I downloaded the same pdf file in Chrome and tried to open this in Adobe Reader version 11.0.22, it gives me the "There was an error opening this document."The file is damaged and could not be opened".Please see the screen shots below
The asp.net application gets the data from a service and renders it on the UI.This is the C# code that does this
var data = getdataAndOtherThingsFromService();
Response.ContentType = "application/pdf";
Response.AddHeader("content-length", data.DocumentStream.Length.ToString());
Response.BinaryWrite(data.DocumentStream);
IE isn't rendering the PDF. As the dialog clearly indicates, the Adobe Reader plugin is attempting to render the PDF but is unable to. That's why you get the same dialog when you download the file and open it.
Chrome, Firefox, and Edge, and even PDF files hosted on Dropbox have their own PDF rendering engines built-in and, apparently, are more forgiving of badly formatted PDF than Adobe Reader is.
Unfortunately, you will never be able to create a consistent experience if you rely on the browser, or browser plugins to render your PDF files. Instead, you'll need to implement something like PDF.js which, while not a perfect PDF rendering tool, will at least behave predictably across browsers and operating systems.
Adding the code below that fixed my issue.This might be helpful to someone in the future
var data = getdataAndOtherThingsFromService();
Response.ContentType = "application/pdf";
Response.AddHeader("content-length", data.DocumentStream.Length.ToString());
Response.BinaryWrite(data.DocumentStream);
Response.End();
I just transitioned my ASP.NET MVC project from Spire.PDF to iTextSharp (due to the limitations in the free version of Spire.PDF). However I cannot get even the simplest example to work correctly for some reason.
What happens is that the browser (IE 11 x64 in this case) will just display an empty grey page. If I keep this page open for a while then Adobe Acrobat displays an error message (103:103).
The interesting part is that when I save the file (either by adding a Content-Disposition header or by using Fiddler) then the PDF opens without problems. I also found out that Edge and the 32 Bit version of IE will display the PDF file just fine.
Here is my sample Action method:
public ActionResult DownloadPdf() {
var document = new Document(PageSize.A4, 50, 50, 25, 25);
var output = new MemoryStream();
var write = PdfWriter.GetInstance(document, output);
var titleFont = FontFactory.GetFont("Arial", 18, Font.BOLD);
document.Open();
document.Add(new Paragraph("Test Receipt", titleFont));
document.Close();
Response.ContentType = "application/pdf";
Response.BinaryWrite(output.ToArray());
return new EmptyResult();
}
This is what the result looks like: https://onedrive.live.com/redir?resid=17E4A59AD907D9BA!259495&authkey=!ABsQUl-TiR668xI&ithint=folder%2cpng
Any ideas other than setting Content-Length or Response.Buffer? (I tried those already)
Update 1: I'd like to reply to some of the comments
#ChrisHaas even after changing the content type, IE would still display the grey page. However, I used Fiddler to save the response (once with header and once without) in the OneDrive link which you can find in my question above.
#Matt do you mean F12 dev tools? It won't load up correctly on the grey page, it's just a blank white area. So I can't really inspect anything.
#Paulo I tried this before and it didn't have any effect. However the Content-Length seems to be correct anyway according to Fiddler.
I still don't understand what exactly the problem is but I decided to test this on a different PC and determine whether it is a server-side or client-side problem.
I reconfigured IIS Express to allow remote connections and accessed the PDF file from another system (also Win 10 Pro x64 with IE 11) and it worked perfectly. It also behaved correctly depending on the content-type (i.e. download dialog for octet-stream and inline PDF viewer for application/pdf).
Next thing I did was reinstall Adobe Acrobat Reader DC on my dev machine but the problem was still there, even after rebooting and clearing the IE cache. So the last thing I tried was downgrading from version DC to X - this actually worked and will now display PDFs in the browser normally.
Like I said, I don't understand exactly what the problem was but at least I can continue working on my project now.
Thanks everyone for the suggestions though!
We have some users who when they open an excel file on my website it takes ages. If they simpely Save as and then open it's quick.
They have the same issue on other sites so it's a problem on their side.
However is there a way to force the browser to only offer save and not offer open?
As noted here:
Is there a way to force the user to download a file from a href link rather than to open it in a browser window?
and here:
Forcing to download a file using PHP
I'm currently using:
Response.ContentType = "application/ms-excel";
Response.AddHeader("content-disposition", "attachment; filename=Report.xlsx");
Response.AddHeader("Content-Length", new System.IO.FileInfo(fileName).Length.ToString());
But this is still offering the open option.
Is there a way to force this or is it simply dependent on the users browser settings.
Just send a different Content-Type (application/octet-stream):
Response.ContentType = "application/octet-stream";
This way the browser doesn't recognize the format and just proposes to save the file.
--- EDIT ----
Today, I got to know another header field, that probably fixes your problem:
"X-Content-Type-Options: nosniff"
Description: "The only defined value, 'nosniff', prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions.[31]"
(http://en.wikipedia.org/wiki/List_of_HTTP_header_fields)
Although the Question is quite old I am going to answer...
For IE8/9 and Chrome this worked for me:
Response.AddHeader("X-Download-Options", "noopen");
I've been asked to implement a security requirement that we instruct browsers not to cache sensitive data. This is all fine for the ASPX content using the standard instructions:
Response.Expires = -1;
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
However when I set these headers for PDF downloads, IE8 won't show the PDF (haven't tried other IE versions yet, kinda moot, I need it working on all of them, even IEfreaking6). Seems to work in firefox 4 beta, but I haven't double checked that it's definitely not caching it. Here is the abridged version of the code I'm using to serve the PDFs:
Response.Clear();
Response.ClearHeaders();
Response.ClearContent();
Response.Buffer = true;
//This stops the PDFs from being viewed :(
//Response.Expires = -1;
//Response.Cache.SetCacheability(HttpCacheability.NoCache);
//Response.Cache.SetNoStore();
Response.ContentType = mime;
Response.AddHeader("Content-Disposition", disposition);
Response.BinaryWrite(file);
Response.End();
Where in the case of PDFs the mime type is set to:
private const string mimeTypePDF = "application/pdf";
The disposition is set to:
var disposition = String.Format("{0};filename=\"{1}\"", SendInline ? "inline" : "attachment", Path.GetFileName(filename));
I'm going to play-around a bit more, maybe forcing them to download as mimetype "application/octet-stream" might work, but that would stop the nice open PDF's in a new browser window from working.
Has anyone had any success with preventing IE from caching PDFs from the server side and successfully displaying them?
Just to give a clear example about what happens. In one scenario user's can select a bunch of reports from a list, these are compiled into a PDF and the PDF is shown in a new browser window. With the caching enabled the browser window opens, but remains resolutely blank.
I've had the same problem with IE a few years ago and let is cache since I didn't have a requirement to disallow it.
However, since users are free to save a PDF document once the browser shows it, how do you plan on prevent them from do that?
Not that this will solve your problem but when sending physical files you should Response.TransmitFile instead of BinaryWrite. It's much faster and more efficient in terms of memory utilization since you don't need to load the entire file in memory before sending it.
Looks like this issue has been resolved in IE9.
I can now successfully execute the following:
Response.Expires = -1
Response.Cache.SetNoStore()
Response.AppendHeader("Pragma", "no-cache")
Response.ContentType = "application/pdf"
Response.BinaryWrite(myByteBuffer)
Response.Flush()
Response.Close()
Enjoy!
I'm going to say it's not currently possible, nothing I tried seemed to get it to work. Try and get your customers to use firefox instead! :)
I also believe it's a bug in Internet Explorer. I was setting the cache-control header to no-cache and having the same problem. Also note that in Internet Options > Advanced > Security there's a 'Do not save encrypted pages to disk' option that could affect it.
Removal of the cache-control header from the response sorted out my issue. I also then tried checking the above mentioned option, and it seemed to work even better for me. Iinstead of storing the PDF in %LocalAppData%\Microsoft\Windows\Temporary Internet Files, it actually caused IE8 to issue a dialog allowing me to choose where to save it (which is actually what I wanted in my case).
This issue of showing pdf (and other document types) in-browser with the use of the no-cache header has been filed as a bug to Microsoft: http://support.microsoft.com/kb/316431. When you try to open a document in this case, IE tries to read it from cache, but it isn't there.
Unfortunately, the folks at M$ said this "works as designed" and users should not use the no-cache header... go figure.
I have a friend experiencing problems testing a web site of mine that provides a CSV export for a report. He says the CSV is output to the screen, and no file is created.
It works fine on my IIS7, Vista, and IE7 setup. I can't get more details at the moment, but I'd like to at least ask: is my code, below, for sending the CSV adequate to be browser/version independent?
Response.Clear();
Response.Buffer = true;
Response.ContentType = "text/csv";
string fileName = GetExportFileName();
Response.AddHeader("Content-Disposition", "filename=" + fileName);
dt.WriteCsv(Response.Output, false);
Response.End();
I'm building fileName to include a date with /separators, which may be causing a problem, but it doesn't affect my machine, and the / gets automagically replaced with _.
I have also used
Response.AddHeader("content-disposition", "attachment;filename=FileName.csv");
which adds the "attachment" text. You might try that to see if it makes any difference for your friend.
There is a known problem in IE6 that do not correctly support the content-disposition meta tag and there are some gotchas in how to compose the various meta tags.
This link from Scott Hanselman details everything about the issue.
Regards
Massimo
Very late to the party very here, so this is more for anyone who came across this issue at a later time. This is in relation to quote "No HTTP header will force IE6 to offer a download."
In PHP I have the headers set as the following for IE to show a 'Save' button, and not just download the file - or display the file in the brower window.
Response.AddHeader("X-Download-Options", "noopen");
Response.AddHeader("X-Content-Type-Options", "nosniff");
The X headers are used to indicate that it is a non-standard header type. Works in IE6.
The only sure fire way to get IE to prompt for a download is to have the CSV file compressed (ie file.csv.zip or file.zip).
See
http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx
Handling MIME Types in Internet Explorer
MIME Type Detection in Internet Explorer
No HTTP header will force IE6 to offer a download. This is especially true for text content, which is 'auto-detected' by IE.
You can try with Content-Disposition attachment; filename=file.csv but I'm not certain it'll always work. If it does, please confirm.
You didn't mention what browser your friend is using. In the end, it could be a bug or non-standard behavior.
The following technique seems to work fine for me: http://www.blackbeltcoder.com/Articles/asp/creating-downloadable-content-dynamically.