views:

639

answers:

2

I have a servlet that sends a file by setting the HTTP Content-Type to "application/zip", the Content-Disposition to "attachment" and writing it on the response's OutputStream; it behaves correctly when deployed on my local application server, making the browser show the popup to choose wheter or not to download the file.

However, when deploying on a clustered jboss server, IE hangs on 0% requesting file information for the whole transfer and then fails with an error message stating that the file wasn't available for download: even stranger is the fact that with FF and Chrome the servlet behaves correctly, i.e. same way as on localhost.

Any clues?

I can also provide a small snippet of the significant part of the servlet code:

response.setContentType("application/zip; name=" + f.getName());
response.setContentLength((int)f.length());  
response.addHeader("Content-Disposition", "attachment;filename=" + f.getName());
byte[] buf = new byte[1024];
int bytesRead;
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(f));
OutputStream os = response.getOutputStream();
while((bytesRead = bis.read(buf)) != -1) {
 os.write(buf, 0, bytesRead);    
}
os.flush();
bis.close();

I don't really know if the problem lies in my servlet code or in the clustered server configuration, but i'm starting to guess the second chance may be the right one...any ideas on what could be wrong in my cluster configuration?

A: 

This is possibly a result of IE behaviour described in these articles:

http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B181050

http://support.microsoft.com/default.aspx/kb/813827

I had a similar problem (only with Tomcat), which only occurred if the file size was large enough. You can easily test if that is the case by measuring the time from starting the download to the error message - if that time is constant, you have probably the same error. You don't possibly see the error locally, because the files load fast enough.

If the timeout results from the time generating the file, one solution would be to create the file in an asynchronous manner and start the download first after the file is ready to be downloaded.

simon
The file is already created asynchronously, so it can't be a problem with its generation, and i don't think it's related to browser timeout since it behaves correctly both locally and on the remote machine when i don't go through the cluster
Raibaz
A: 

Ok, i fixed it.

The load balancer standing between the client and the individual cluster servers was adding 'Cache-Control: no-cache' to every HTTP response, which caused IE to get mad.

Removing the header directive solved the problem.

Raibaz