Download path URL-encoded in IE5.5

Printable View

October 3rd, 2002, 01:37 PM
websmith99

Download path URL-encoded in IE5.5

I have another challenge for you folks.

This is happening only on IE5.5 (Windows 2000).

In my Web Application (JSP architecture) I have a download link where the user can download some dynamically generated HTML document particular to them. Rather than display the document in the browser, I have purposely set the content type in the HTTP header to "text/x-application-download" using JSP so that when the user clicks on the link they will get the following dialog box:

-------

You have chosen to download a file from this location. What would you like to do with this file?

O Open this file from it's current location
O Save this file to disk

-------

That way they can save the file locally rather than viewing the source and saving that locally.

If you select "Save this file to disk" and then subsequently open the file everything works correctly.

HOWEVER, if you choose "Open this file from it's current location", the browser attempts to open the file from the Temporary Internet files folder but gets a 404 not found error.

An example of the path is:
C:\Documents%20and%20Settings\Administrator\Local%20Settings\Temporary%20Internet%20Files\Content.IE5\CP2RGHIV\allnotes_download[1].html

Note that the URL has spaces encoded to %20. In fact, if I remove the filename at the end of the path, it can't even find the directory \CP2RGHIV. But if I manually remove the URL encoding from the URL in the location bar of the browser, then it does find the directory.

On IE6 where the bug doesn't happen the spaces are not encoded.

Why is IE5.5 URL-encoding the path to the Temporary Internet files directory? Is there a browser setting to do this? Is it a bug in IE5.5 when you set the set the content type in the HTTP header to "text/x-application-download"?
October 3rd, 2002, 05:21 PM
Waldo2k2

i don't have a clue, but from what you say, it's probably a IE5.5/win2000 bug. Probably has to do with how the two together deal with application downloads and the cache. Seems like you've had quite a tough time with ie5.5 (referring to prior posts)
October 4th, 2002, 05:03 PM
websmith99

I fixed this. It turns out that IE5.5 does have a bug. Unlike IE6 where you can set either the content type or the content disposition in the HTTP header to force a "save as" dialog box when downloading a file of a given mimetype, IE5.5 needs you to set both.

I added in the content disposition, and it now works:

StandardBrowserRequest br = (StandardBrowserRequest) request.getBrowserRequest();

String extraPath = br.getExtraPath();

setHeader(request, "Content-Disposition","attachment;filename=" + extraPath);

setContentType(request,"text/x-application-download");

Quote:

Seems like you've had quite a tough time with ie5.5

Yeah, I've come across some pretty quirky bugs with IE5.5, though I think the quirkiest browser yet is NN4.x
October 30th, 2002, 08:04 PM
websmith99

This nasty bug appeared again. It turns out that my fix works in the development environment, which uses jboss & tomcat as a web application server. But when the fix was moved to the production environment, which uses WebLogic application server, the bug still occurs.

I used a packet sniffer to compare the HTTP headers in the jboss/tomcat environment vs. the WebLogic environment and both headers contained the content disposition and the content type. There were no other noticeable differences in the HTTP headers.

Still, somehow when WebLogic is used as the app server the bug occurs. I have run across WebLogic-specific issues in the past but this one is puzzling.

Any help is greatly appreciated.
November 12th, 2002, 05:53 PM
ShawnDev

Re: Download path URL-encoded in IE5.5

Quote:

Originally posted by websmith99
Why is IE5.5 URL-encoding the path to the Temporary Internet files directory?

Um... because IE is stupid? ;)

Quote:

Is there a browser setting to do this? Is it a bug in IE5.5 when you set the set the content type in the HTTP header to "text/x-application-download"?

I would call this a bug, but not with "text/x-application-download". You're doing something the browser doesn't expect you to do - and the developers didn't account for this odd situation. That's my take on it, anyway.
November 12th, 2002, 06:24 PM
websmith99

Thanks for the feedback/ opinion.

Feel like taking on some real challenges?

1. Weeding out UTF-8 characters using JavaScript
last post: 10-25-2002

2. printing absolutely positioned content in IE5.5
last post: 10-16-2002

3. Preserving japanese characters with document.open()
last post: 10-16-2002

If you can SOLVE any of these then you are a true guru.