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();
Related
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");
We're using ABCPDF.Net 8 to generate PDF documents for users. The HTML source is loaded directly as a string and images are defined in the HTML with the full path. Example:
<img id="img1" src="file://D:/trakit/images/cl_logo.gif" alt="" />
This works beautifully and we have about 200 users generating PDFs with no problem.
The problem is that a few handful of users are not getting the images in the PDF. The images are replaced by the image placeholder that is shown by IE when an image is not found.
This happens consistently for some users only. I cannot figure out what is wrong as the PDF is generated server-side and should not have anything to do with the user's browser settings. I agree that the page/code is running under the user's permissions (we use windows authentication), but why should this affect PDF image generation? Below is the code snippet to generate the PDF:
PDFDoc.Rect.Inset(20, 20)
PDFDoc.Page = PDFDoc.AddPage()
li_PDFID = PDFDoc.AddImageHtml(as_HTML, True, 1050, True)
While PDFDoc.Chainable(li_PDFID)
PDFDoc.Page = PDFDoc.AddPage()
li_PDFID = PDFDoc.AddImageToChain(li_PDFID)
End While
For li_Loop = 1 To PDFDoc.PageCount
PDFDoc.PageNumber = li_Loop
PDFDoc.Flatten()
Next
Return PDFDoc.GetData()
Any help will be greatly appreciated.
Thanks.
Update: Just found that if the user users another browser (such as Firefox), the images then generate fine. This narrows down the problem to IE 7/8 on the user's computer. Any suggestions?
Okay. The issue was finally found and has nothing to do with ABCPDF.
Seems part of the HTML source was coming from the user's browser - obtained using javascript function innerhtml() on IE. And I just found out that IE has a big problem with innerhtml()
All sorted now.
I am trying to allow the user to download an excel file, by using
Response.Redirect(
"http://localhost/myapp/download_folder/example excel file_july.xls")
in page load of an ASP.net page
but on the client side i a m getting the following screen in firefox 3.5
You can observe that the file name and file type are shown as empty fields. The ok and cancel buttons are not doing anything.
This happens only in firefox 3.5, it is working in firefox later versions and other browsers.
I tried clearing the Response with Response.Clear(), using Response.BinaryWrite with the file byte array and even tried to open the file with the javascript by calling window.open(url).
you are doing it the wrong way.
just as an example, look at what is done in the question body here:
How to download file and reload
in your case you should probably use an overload of Response.Write.
the point is that you should set some Response headers to tell the browser file name, file length and content type at least.
I'm using uploadify (http://www.uploadify.com/) to upload video to my site then convert them into *.flv using ffmpeg and play preview. But it dosen't fully working with firefox， chrome or safari.
uploadify provides a onComplete interface, so when the script (.ashx, .php) used on your site for saving uploaded files. you can use response.write("blabla") or (echo "blabla") to invoke the javascript function that registed as OnComplete.
i have test with few video files like avi, mpg, mp4, they are less then 50mb,and they all worked with all 4 browsers. However, when i was trying to upload a 75mb mp4 file, it worked in IE, but didn't working in other three. I can see the .flv file has been create in the upload folder, i can see debug messsage output after response.write("blabla"), but the javascript function was not invoked. i.e. the preview didn't play.
anyone knows why? is there a timeout or something on response.write so after a period of time it wont work? e.g. 75mb file took longer time to convert than other smaller size file i tried.
thansk
Could be a timeout from the server or caching issue. Or an incorrect uploadifiy property as stated here
after a deeper looking in the source code, and googling around. the problem is narrow down on
DataEvent.UPLOAD_COMPLETE_DATA and firefox issues
someone reported bug
http://bugs.adobe.com/jira/browse/FP-1419