Uploading a file using FileUpload control fails in IE8

I had another interesting customer issue this week, where in uploading a file using the FileUpload control was failing only with IE8. As you would do with any client-side issue, I started by collecting Fiddler traces for both the working (IE7) and non-working (IE8) scenarios. Following were the observations:

· IE 7
        Content-Disposition: form-data; name="targetFile"; filename="C:\Users\<username>\Desktop\test.txt"
· IE 8
        Content-Disposition: form-data; name="targetFile"; filename="test.txt"

The question that struck me was - Why would a client-side behavior affect my application? So I started reviewing the code on the server. The customer had server-side code to parse the filename and look for “\” to determine the filename extension (although this can easily be determined using the FileName property of the FileUpload control). This server-side code was failing in the case of IE8 because the entire path was not being passed and hence no “\”.

While researching further on this to determine why IE8 does not send the complete file path to the server, I came across an IE blog here. It explains that this is one of the security features implemented in IE8. An excerpt from that blog (below) explains this:

Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\<username>\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.

Further to this, I gave the following options to the customer:

1. Change the logic in the server-side code - It should not be dependent on the client-side file path location and should simply use the FileName property of the FileUpload control.

2. Enable the IE 8 option to include the local directory path for the Internet Zone on the client-side.

clip_image002

However considering the number of end users a web application could have, it’s always better to control things on the server-side rather than asking client users to change their configuration.

Till then bye bye…