From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 BuildID: 2002051013 (RC2) The "Content-Disposition: attachment..." header appears to go totally unnoticed, neither forcing download of otherwise inlineable content-types nor using the filename property to set a default for the save as window for unknown or known and download-only content-types. Here are the headers returned from my server: ------------------- HTTP/1.0 200 OK Set-Cookie: ad_session_id=4050005%2c0%20%7b61%201021561982%20BC830E710683272F6E923B4F4B01B117E898B1B0%7d; Path=/; Max-Age=1200 Content-Disposition: attachment; filename=test.txt Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Date: Thu, 16 May 2002 14:53:02 GMT Server: AOLserver/3.3.1+ad13 Content-Length: 5 Connection: close ------------------- The result is displayed in the browser and no download window pops up, contrary to the content-disposition header. If the MIME type is changed to application/octet-stream or a nonexistent mime-type (nonexistent/type), the download window appears, but it is defaulted to the filename derived from the URL requested instead of that specified by the filename= parameter of the content-disposition. I apologize for not being able to provide a URL, but my site is in development and not publicly accessible. Is this a regression? Other bugs in bugzilla seem to suggest that the functionaly exists or did exist in the past. Is it related to the cookie being set during the same connection? Am I doing something wrong? Not that this is a demonstration of correctness, but IE handles it correctly.

dup of bug 62760 or bug 98360?

ahh there's also bug 65827

Is there a test url? This is mostly bug 98360 but we _should_ be respecting the filename param -- I know the code is there to do it...

I opened up the HTTP Auth on the server for a little while... hopefully this will help in verification, but this URL won't be around forever. The script in question returns a file with a content type of text/plain containing the value of the text param and sets the content-disposition filename to the value of the filename param. http://140.239.165.196:8000/testing/echotext?text=filecontents&filename=file.txt

John, thank you for the testcase. When I load that url, it's shown inline (bug 98360). When I select "save as", "file.txt" is the suggested filename.... Is that what you are seeing? Could you make that url return application/octet-stream instead of text/plain so that the filename= thing can be tested? Thanks!

I hadn't tested that. I get the same result so that much, at least, works (which is actually a reasonable UI comprimise for my site; IE users get an auto-download, and Moz users at least get the right filename if they choose to save it). Any idea on what's going wrong with the other two cases?

What are the other two cases? I have a very good idea why it's showing up inline. I have no idea why sending as application/octet-stream is not prompting with the right filename, and I can't reproduce that problem on my local test setup....

OK... I reviewed my testcase. I was confused by the automatic extension replacement bug into thinking that the application/octet-stream version was not honoring the filename at all. All facets are covered by the other bugs referenced in the comments -- all I needed was a reasonable workaround, which for me turned out to be using a nonexistent mime type along with a content-disposition/filename= header (which apparently does work after all). Use of a nonexistent MIME type avoids the automatic extension-appending problems of bug 65827, so I'm happy, despite the nastiness of using fake MIME types.

John, thank you! And I'm hoping to have time this summer to deal with the extension thing and the inline rendering... *** This bug has been marked as a duplicate of 98360 ***

Verified dupe.