From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) BuildID: 20020514 Downloading dialog incorrectly uses Windows 'shell' filetype mapping with the retrieved URL to figure out filename for the saved URL. The borwser should instead use the filename specified in HTTP header Content-Disposition, filename attribute. The URL should have no effect on the saved filename if Content- Disposition header with filename is present. Currently test.asp URL with filename=test.csv results test.csv.asp as the filename offered in the download dialog. Reproducible: Always Steps to Reproduce: 1. Install Windows 2000 and IIS (or use equivalent techogy such as JSP on Tomcat) 2. Create the following test ASP script (or equivalent e.g. JSP page): <%@ Language=VBScript %> <% Option Explicit %> <% Response.AddHeader "Content-Disposition", "attachment; filename=test.csv;" Response.ContentType = "text/csv" Response.Write """First"";""Second"";""Third""" %> 3. Retrieve the URL; Browser doesnt use the specified filename 'test.csv' as default, but instead it concatenates part of URL and uses Windows Explorer file type mapping, identifiying the file as 'Active Server Document'. Thus filename test.csv.asp is used as the default. Usually this is not the desired behaviour. 4. No, this bug has nothing to do with IIS; HTTP headers returned by IIS are completely ok and are as follows: HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 20 May 2002 17:21:45 GMT Content-Disposition: attachment; filename=test.csv; Content-Length: 24 Content-Type: text/csv Cache-control: private Actual Results: Had to rename the file manually every time. This is very frustrating. Opening the file using associated software fails since the filetype of .asp is used and not .csv Expected Results: Mozilla should have used literally filename 'test.csv' as steted in the HTTP header: 'Content-Disposition: attachment; filename=test.csv;'
I don't know enough to really judge how this might differ to them but this is related to or a duplicate of bug 65827 and bug 120327
I'm having the same problem on a JSP/iPlanet platform.
This bug doesn't exist in Netscape 6.2, but it does in the latest Mozilla builds and Netscape 7 as well, a regression?
*** This bug has been marked as a duplicate of 65827 ***