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

VERIFIED DUPLICATE of bug 98360

Status

Core Graveyard
File Handling
VERIFIED DUPLICATE of bug 98360
16 years ago
2 years ago

People

(Reporter: John Mileham, Assigned: Darin Fisher)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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

16 years ago
dup of bug 62760 or bug 98360?

Comment 2

16 years ago
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...
(Reporter)

Comment 4

16 years ago
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!
(Reporter)

Comment 6

16 years ago
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....
(Reporter)

Comment 8

16 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 10

16 years ago
Verified dupe.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh

Updated

15 years ago
Component: Networking: HTTP → File Handling
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.