struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shannon, Andrew" <andrewshan...@pqa.com>
Subject file download problem in application server
Date Wed, 25 Mar 2009 13:25:32 GMT
I posted this question on the OTN - OC4J list a second ago, but am
hoping someone here might have some insight.

 

"I have a web app running in an OC4J stand alone 10.1.3.3 and am having
a problem with downloading files over http. Its a struts2 app whose file
downloading impl is easy to use and standard code for writing to an http
servlet response output stream.

Using the firefox plugin for Live Headers I can see that the headers are
correctly added to the servlet response and I do get the file I want.
However the file has been mangled with binary output around the text.
This is the case for txt, word, or any other file.

This problem does not occur in Jetty or Tomcat. I've also ruled out file
corruption while going in/out of the database since I can upload a file
when running oc4j, turn off oc4j, start up my app in Jetty and retrieve
the same file just fine.

The mime types are all accounted for and the problem exists regardless
if I use a specific content type or just application/download. My
browsers (firefox and ie) also recognize all files from the content
disposition value "attachment; filename=myfilename.ext". Its just the
file content that some how has been wrecked on the way out of the
container.

Has anyone experienced this? I only found one or two unanswered posts
elsewhere.

How can this be mitigated?"

 

What I didn't include in the above post is that we're on s2 2.0.14, also
that I put on my pirate hat and created a custom result type based on
the StreamResult so that I could specifically set some additional
response headers.  It all works great in a servlet container, but I'd
like to know if you all have seen this problem in application servers
like oc4j or jboss and if so what did you do to fix it?  I'm open to any
suggestions.

 

Thanks a bunch,

Andrew

 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message