145024 - "Content-disposition: attachment; filename=" not honored

Status: VERIFIED DUPLICATE of bug 98360

(Core Graveyard :: File Handling, defect)

Description

[John Mileham]

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.

Comment 1

[R.K.Aa.]

dup of bug 62760 or bug 98360?

Comment 2

[R.K.Aa.]

ahh there's also bug 65827

Comment 3

[Boris Zbarsky [:bzbarsky]]

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...

Comment 4

[John Mileham]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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!

Comment 6

[John Mileham]

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?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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....

Comment 8

[John Mileham]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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 ***

Comment 10

[John Unruh]

Verified dupe.