March 31st, 2003, 04:11 PM
I use zn HTML template and after I write to the XML file to the stream I do not re-print the template because I do not want the code of the template to end up in the XML file.
Here is the code I use.
res -- HttpServletResponse object
bout -- is a ByteArrayOutputStream that I write to the XML file to until I know I'm ready to write it to the stream.
filename -- is the name of the file i want to name it.
"attachment; filename=" + filename + ";");
Now I don't set the content type to "text/xml" because then IE will attempt to render it directly to the browser since it recognizes what an XML file is.
I would appreciate any help. Thanks
April 1st, 2003, 07:05 AM
Well, quick fix, try targeting you download form to "_blank". If that doesn't work, can you post some more code (the html page, maybe)? This doesn't sound like its your java code that's causing the problem.
April 2nd, 2003, 11:07 AM
I changed the target on the form to target="_blank" and all it did was open it in another window. This is no good, because I currently use frames and the middle contains this page to download from. Plus any action I called on this page, even if it isn't for a download it will open it in a new window.
<body class="pgSetup" onLoad="init();">
<form NAME="Servletname" METHOD="post" ACTION="/servlet/form/Servletname" onSubmit="return validate(this);">
<INPUT class="input" TYPE="text" NAME="id" SIZE="4" MAXLENGTH="4" VALUE="" ONCHANGE="validateField(this,' ')">
Hope this helps. If you need anything else let me know.
April 2nd, 2003, 11:32 AM
I don't see that happening from what you've posted, but double check that all of your frames have pages loaded from the same server (hostname and port).
April 2nd, 2003, 05:36 PM
I am desperate for any help. Thanks
April 3rd, 2003, 12:47 AM
April 15th, 2003, 07:27 PM
I have the same problem.
Did you have solution for this problem. I appreciate your help.
Thanks a lot.
April 17th, 2003, 08:47 AM
I would suggest for a possible workaround that you might want to try opening a new "download" window that allows the user to download the file from there instead.
So the order of operations would be:
[list=1][*]User clicks on button (or whatever) to say it wants to download the xml file.[*]Open new window and load a "download" page that requires the user to click a button or link to download the file.[*]This download window closes (think of it as a dialog window) and the user is prompted to download the file as usual. [/list=1]
This adds one redundant step to the process, but may get you around your problem. Basically, since downloading the file seems to screw up the IE window where the download was initiated from, maybe openeing and performing the operation in a new window will keep this from happening. Hope this helps.
I too am experiencing the same problem, except that my server-side resource is Perl. We batch produce Excel reports for many of our clients and deliver them via the web. Our clients grab their reports via a HTML form that has a wizard look and feel, i.e. 1. select a, 2. select b, etc. When the users clicks the "download" button, the window's location is set to the Perl script and a CGI string with the selected parameters.
We are noticing this problem with IE 5.0, 5.5 and I believe 6.0. I believe our web server is Apache. The really weird thing is that the methods described above used to work as of a couple of weeks ago. We haven't undertaken any browser upgrades that I'm aware of. What is also weird is that opening the document in the browser doesn't seem to cause the problem. It is almost as if the document's contents need to change if the location changes. If not, all references are lost and hence the "Access is denied" error.
Does anyone else have any thoughts?
Thanks in advance...
Sabeur was kind enough to e-mail me with the below IE5.5 bug report. I'm forwarding it on along with some other workarounds that I've ended up using to solve the problem.
Another option that I've come up with would be to have a hidden applet sit on your page and have it open up a URL connection to the server and then show the "document" returned. I've used this quite frequently to grab data from the server and refresh the page via DIV tags w/o having to re-draw the entire window. The applet will only be about 6K so the download/footprint is negligible. The "showDocument()" method will trigger IE and presumably Netscape (haven't tested it) to open up the download window.
// Define a URL object representing the applet
URL appletURL = this.getDocumentBase();
// Parse the applet's URL to get the full address string
String perlURL = appletURL.getProtocol() + "://" +
appletURL.getHost() + appletURL.getFile();
// Hack off the HTML page name from the URL and add my perl
// script file name and any CGI parameters that I wish to
// pass that are set in strURLString
perlURL = perlURL.substring(0, perlURL.lastIndexOf("/"));
URL fileURL = new URL( perlURL + "/report_intrf.pli" +
// Execute connection and show contents to browser.
Of course you would need a bit more in your code, but this would essentially be the working guts of it.
A third option is to have a new window open which causes the download. It avoids the error, but the user is left having to close the window unless you do some fancy onBlur type of stuff - which might stop the download if the user clicks away from the window.
I hope this answers people's question. Please feel free to contact me should you have any questions.