Persits Software, Inc. Knowledge Base Articles

File downloads via SendBinary are broken in Netscape 7

Problem Description

File downloads via SendBinary cause Netscape 7.x to show an incorrect file name. Instead of displaying the filename of the file being downloaded, Netscape appends an extra extension resulting in a filename such as "filename.gif.asp".


Browsers based on the "Gecko" engine (Netscape 6+, Mozilla, and others) must see a Content-Type in the HTTP header that matches the extension of the file being downloaded. If it does not match, the browser appends the extension of the original URL request such as ".asp". This is by design, to comply with standards and to reduce the possibility of unsecure or dangerous content masquerading as as a safe MIME type.

For downloads using AspUpload, you must not specify a generic Content-Type such as "application/octet-stream". Instead, call SendBinary without specifying a Content-Type:

Path = "c:\directory\filename.txt"
Upload.SendBinary Path, True, , True

AspUpload searches for the file extension in the server's system registry under HKEY_CLASSES_ROOT to locate a proper Content Type ("text/plain" in this case) and sends it to the client browser.

Also ensure that you are using the latest update of AspUpload, which is


If a registry entry for that file extension is not found, AspUpload sends the file with "Content-Type: application/octet-stream". This causes Netscape 7.x to append the incorrect extension. Certain valid Content-Types such as "application/x-msdownload" for .EXE files cause similar behavior by design in Netscape, because .EXE files can be dangerous to automatically download or run. There is no known solution for downloading these types of files to Gecko browsers with AspUpload; users must manually change the suggested filename.

Also, this may break file downloading in old browsers such as Netscape version 4.x that do not recognize the "Content-Disposition: attachment" header. Certain file types such as .txt and .gif will be displayed within the browser window instead of presenting a save dialog. Solutions to this are:

- Instruct your users to use a newer browser, or instruct them to use Save As to save the file after the browser displays it

- Write ASP code to detect the client browser and version, and have AspUpload use "application/octet-stream" only for Netscape 4.x

A workaround to all of these issues is to send an HTTP REDIRECT request (Response.Redirect in ASP) to instruct the client browser to download the file directly (without AspUpload), but this is only possible for files that exist in a directory accessible via the web.