sbolisetty
asked on
Adobe FDF Toolkit causing problems with Internet Explorer but not in Mozilla
Hi
I am a beginner to PDF/FDF and facing this silly behavior from
Internet Explorer I am trying to solve.
I have a simple Java (JSP) page that returns FDF stream with
content-type: application/vnd.fdf. In Mozilla this page works - by
opening a new browser instance that in turns open the Acrobat inside
the IE-Browser (not sure why this is happening). But this solution
eventually brings up the PDF with the data as set in the FDF stream.
But the same page when tried from IE bring up this, instead:
==========================
File-Download
Some files can harm your computer. If the file information below looks
suspicious, or you do not fully trust the source, do not open or save
this file.
File name: mypage.jsp
File Type: Adobe Acrobat Control for ActiveX
From: intranet.myserver.net
This type of file could harm your computer if it contains malicious code.
Would you like to open the file or save it to your computer?
==OPEN== ==Save== ==Cancel== ==More Info==
==========================
Clicking on "OPEN" or "SAVE" buttons give the following error window
and the IE closes. The other buttons are of no help.
==========================
Microsoft Internet Explorer
Internet Explorer cannot download mypage.jsp from intranet.myserver.net.
Internet Explorer was not able to open this Internet site. The
requested site is either unavailable or cannot be found. Please try
again later.
==========================
When I access the page from Mozilla, I get two requests on the server
- one for my JSP and another for the PDF itself (as referred in the
FDF stream). But when I do this from IE, I get only the JSP request
back to the server but not the PDF request. The JSP page requests both
are returned by the web-server with status code 200 and same
content-length (in this case 2812).
I then changed the content-type from "application/vnd.fdf" to
"text/plain". I could simply access the entire FDF stream in the
browser - both in Mozilla and IE. I could use browser's SAVE feature
to save this into a file - test.fdf. Then I could simply double click
this "test.fdf" and open the PDF with content from the FDF-stream.
Everything worked as expected and as it should in this test.
I am wondering why Internet Explorer is behavior so badly to the
request for this specific content-type from my Unix-Solaris server.
Thank you in advance for any pointers.
-Srinivas
I am a beginner to PDF/FDF and facing this silly behavior from
Internet Explorer I am trying to solve.
I have a simple Java (JSP) page that returns FDF stream with
content-type: application/vnd.fdf. In Mozilla this page works - by
opening a new browser instance that in turns open the Acrobat inside
the IE-Browser (not sure why this is happening). But this solution
eventually brings up the PDF with the data as set in the FDF stream.
But the same page when tried from IE bring up this, instead:
==========================
File-Download
Some files can harm your computer. If the file information below looks
suspicious, or you do not fully trust the source, do not open or save
this file.
File name: mypage.jsp
File Type: Adobe Acrobat Control for ActiveX
From: intranet.myserver.net
This type of file could harm your computer if it contains malicious code.
Would you like to open the file or save it to your computer?
==OPEN== ==Save== ==Cancel== ==More Info==
==========================
Clicking on "OPEN" or "SAVE" buttons give the following error window
and the IE closes. The other buttons are of no help.
==========================
Microsoft Internet Explorer
Internet Explorer cannot download mypage.jsp from intranet.myserver.net.
Internet Explorer was not able to open this Internet site. The
requested site is either unavailable or cannot be found. Please try
again later.
==========================
When I access the page from Mozilla, I get two requests on the server
- one for my JSP and another for the PDF itself (as referred in the
FDF stream). But when I do this from IE, I get only the JSP request
back to the server but not the PDF request. The JSP page requests both
are returned by the web-server with status code 200 and same
content-length (in this case 2812).
I then changed the content-type from "application/vnd.fdf" to
"text/plain". I could simply access the entire FDF stream in the
browser - both in Mozilla and IE. I could use browser's SAVE feature
to save this into a file - test.fdf. Then I could simply double click
this "test.fdf" and open the PDF with content from the FDF-stream.
Everything worked as expected and as it should in this test.
I am wondering why Internet Explorer is behavior so badly to the
request for this specific content-type from my Unix-Solaris server.
Thank you in advance for any pointers.
-Srinivas
No, it doesn't work. It says the file could not be written to the cache. When IE thinks the adobe-plugin for FDF is harmful, it would not let that slip by as simple as that.
-Srinivas
-Srinivas
ASKER
SOLUTION:
There is no 'easy' solution to this problem as this is a possible bug in Acrobat Reader software that employs Active-X control to open a PDF document and merge it on the fly with FDF stream to show the final PDF. This bug happens only if I am using HTTPS and not HTTP. Probably folks at Acrobat doesn't know enough about Active-X controls to write a clean one that can work under both protocols. Too bad!
The solution I am going ahead is to employ FDFMerge from Appligent.Com that merges FDF data into a PDF on the server and returns the completed PDF on the fly. This is a bit of processing overhead on the server but is much cleaner and as it turned out very much preferred in my case. Hope this helps someone.
-Srinivas
There is no 'easy' solution to this problem as this is a possible bug in Acrobat Reader software that employs Active-X control to open a PDF document and merge it on the fly with FDF stream to show the final PDF. This bug happens only if I am using HTTPS and not HTTP. Probably folks at Acrobat doesn't know enough about Active-X controls to write a clean one that can work under both protocols. Too bad!
The solution I am going ahead is to employ FDFMerge from Appligent.Com that merges FDF data into a PDF on the server and returns the completed PDF on the fly. This is a bit of processing overhead on the server but is much cleaner and as it turned out very much preferred in my case. Hope this helps someone.
-Srinivas
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Srinivas,
I'm having the same issue, but from a user perspective. As far as I can tell it is a problem with the IE security settings, as I can access the PDFs if I turn off some of our browser security options, but when they're on I have the "File Download" issue and the PDF won't open. Unfortunately I haven't been able to determine what security setting is causing this...The issue occurs accessing a PDF over HTTPS.
Any other ideas? I think that the site is serving static PDFs and not using FDF.
I'm having the same issue, but from a user perspective. As far as I can tell it is a problem with the IE security settings, as I can access the PDFs if I turn off some of our browser security options, but when they're on I have the "File Download" issue and the PDF won't open. Unfortunately I haven't been able to determine what security setting is causing this...The issue occurs accessing a PDF over HTTPS.
Any other ideas? I think that the site is serving static PDFs and not using FDF.
ASKER
I haven't run across any problem using static PDF over HTTPS. The browsers (both IE and Mozilla) seem to work just fine. My best guess might be the MIME-TYPE is not setup on your server.
-Srinivas
-Srinivas
The odd thing is it works OK if I turn down some of the IE security settings... I guess I"m just going to have to plow through each one to find what it takes to fix it, as the "standard" settings are locked up in an IE Autoconfiguration setting and I can't even see what they are directly. What a hassle.
Thanks for your input however!
Thanks for your input however!
Select "Open with", and then choose IE and check the "always" box
IE should now be able to handle jsp pages...
Thanks,
Sean