98360 - [FIX]content-disposition: attachment is ignored if known content-type specified

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect, P1)

Description

[Rick DeBay]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080110

If multipart/mixed data with an item specified to be downloaded is sent
with a known mime type, Mozilla will display the item instead of saving.

If Content-Type is set to application/octet, it will prompt to save a file of
unknown type.  It also ignores the suggested file name, but I think there is a
bug written for that.

Reproducible: Always
Steps to Reproduce:
1. Send stream to browser.
2.
3.

Actual Results:  Text was displayed in browser window.

Expected Results:  Prompted to save a text file called test.txt

Sample:

Content-Type: multipart/mixed;boundary=Vhg5N7Gbj70Lgs6

--Vhg5N7Gbj70Lgs6
Content-Type: text/plain

Assembling document. This may take a minute.

--Vhg5N7Gbj70Lgs6
Content-Type: text/html

The document has been Assembled. If the download does not begin automatically
click <A HREF=\test.txt>here</A>

--Vhg5N7Gbj70Lgs6
Content-Type: text/plain
Content-Disposition: attachment; filename=test.txt

A file containing text with which to test downloading.
--Vhg5N7Gbj70Lgs6--

Comment 1

[Christopher Hoess (gone)]

Moving to Networking: HTTP.  Maybe related to bug 62760?

Comment 2

[Rick DeBay]

NS 4.77 will also display image/jpeg instead of presenting a download dialog.

Comment 3

[neeti]

darin

Comment 4

[Darin Fisher]

should content-disposition really imply saving the file instead of viewing it?
that doesn't seem right to me... i'm leaning toward marking this bug INVALID.

Comment 5

[Bradley Baetz (:bbaetz)]

rfc2616 says:

"   The Content-Disposition response-header field has been proposed as a
   means for the origin server to suggest a default filename if the user
   requests that the content is saved to a file. This usage is derived
   from the definition of Content-Disposition in RFC 1806 [35].
...
   If this header is used in a response with the application/octet-
   stream content-type, the implied suggestion is that the user agent
   should not display the response, but directly enter a `save response
   as...' dialog.
"
I agree that this is invalid, and that bug 62760 covers the last paragraph.

Comment 6

[Darin Fisher]

marking INVALID

Comment 7

[Rick DeBay]

Reopening.  This header was designed to require action from the user.
I don't specify application/octet as I want the browser to present the user
with options other than just save, if available.  For example, setting
content-type to image/tiff should cause a browser to offer to open a tiff
viewer if one is registered, or to save.
Regardless, RFC-2183 states that the attachment type requires explicit user
intervention before any action (such as display) is taken.

http://www.faqs.org/rfcs/rfc1806.html
2.2  The Attachment Disposition Type
   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.

3.  Examples
 The following body part contains a JPEG image that should be
   displayed to the user ONLY IF THE USER REQUESTS IT. If the JPEG is
   written to a file, the file should be named "genome.jpg":

         Content-Type: image/jpeg
         Content-Disposition: attachment; filename=genome.jpeg
         Content-Description: a complete map of the human genome

http://www.faqs.org/rfcs/rfc2183.html
2.9  Content-Disposition and Multipart
 If the `attachment' disposition is used, presentation of the
   multipart should not proceed without explicit user action.  Once the
   user has chosen to display the multipart, the individual subpart
   dispositions should be consulted to determine how to present the
   subparts.

4.  Summary
   Content-Disposition takes one of two values, `inline' and
   `attachment'.  `Inline' indicates that the entity should be
   immediately displayed to the user, whereas `attachment' means that
   the user should take additional action to view the entity.

...and so on ad nauseum.

Comment 8

[Bradley Baetz (:bbaetz)]

Both those rfcs are to do with mail messages, and attachments within those
messages. I agree that what you are suggesting probably makes sense for mail,
and if we do not follow those rfcs then bugs should be filed in teh mailnews
component.

"For example, setting
content-type to image/tiff should cause a browser to offer to open a tiff
viewer if one is registered, or to save."

We do that currently, and we if you choose to save then we use the content
disposition header as the default filename (well, we did last time I looked -
see bug 87888. You mention that this isn't working, though. You may want to try
a more recent version)

Do other browsers behave as you suggest they should?

Comment 9

[Rick DeBay]

Well, the Evil Empire (TM) gets it right:
http://support.microsoft.com/support/kb/articles/Q260/5/19.ASP
and they even reference RFC-1806 (which is superceded by 2183).

Do a Google search on Content-Disposition:
http://www.google.com/search?q=content-disposition&sourceid=mozilla-search
There are some archived mail-lists with good discussions on this topic.
From a post by Jim Gettys:
"Content-Dispostion was implemented in Web browsers BEFORE it was added
to the HTTP/1.1 spec, to document existing practice.  It is indeed
quite useful, when people are downloading code, to be able to provide
a file name for "save as" to work."
The applicable section is:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
Given that it's been in since Netscape 2.0 (but never working quite right)
I'd think it would be good idea to fix it.

My comment about TIFF was just an example.  The reason it happens to work is that
Mozilla doesn't handle TIFF natively.  And if this were fixed, bug 62760
would automagically be fixed, as the only valid choice for application/octet
is to save as nothing else can handle it.

Comment 10

[Bradley Baetz (:bbaetz)]

The important quote from the http rfc is: "if the user requests that the content
is saved to a file", and we do this.

However, if ie does it, then I guess we should consider this, so I'll confirm this.

Also see http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0452.html on
interaction with content encodings

darin? mscott?

Comment 11

[Rick DeBay]

"...and we do this."

Nope, that's what this bug report is about.  If the mime type is handled
natively (plain/text, image/jpeg, etc) then the item is displayed inline
without any user prompting.  The example given at the beginning of the bug
uses text, in the actual code the problem file is JPEG.

IE tries to do this correctly, but they break it in every other release.
They do patch it eventually, though.  And don't get me started on their mime
type sniffer.

Comment 12

[Bradley Baetz (:bbaetz)]

I meant that we do this "if the user requests that the content is saved to a
file", as the http rfc says. (Actually, I don't know if we do if the user does
file->save as)

Comment 13

[Rick DeBay]

OK, I misunderstood.  This addresses the filename portion of
content-disposition,  but makes no distinction between inline and attachment.

IE currently puts up the dialog:
You have chosen to download a file from this location.
(some URL here)
What would you like to do with this file?
x Open this file from its current location
x Save this file to disk

The downside is that if you choose to open it, rather than display it inline
IE launches MS Paint (I'm testing with JPEGs).

Comment 14

[Darin Fisher]

not sure if we want to make this change, but i'll defer that decision until
later --> future

Comment 15

[Rudolf Balada]

This bug maight be tightly connected to bug 62760

Comment 16

[jsp]

I'm not certain that this is identical to bug 62760, but it is at least very
similar, though the messages in 62760 are not multipart. A good fix for one
might well fix the other.

The ability to have content-disposition: attachment consistently respected as
meaning "give the user the option to save this" takes some power from the
browser and gives it to the server and the user, making it possible to do things
like saving XML documents to the local disk for later uploading and/or email
transmission. If the server wants the browser to display the document (assuming
the browser is capable), it can omit the content-disposition header. If the
browser ignores the content-disposition header and displays the content any time
it is capable of doing so, it restricts the server's choices. I think Mozilla
will serve the Web best if it allows other parties on the Web (like servers)
maximum flexibility.

Comment 17

[Darin Fisher]

mscott: what is your feeling on this?

Comment 18

[jsp]

Bug 62760, as originally written, appears to be fixed. The Mac doesn't behave
quite the same as Windows, but it no longer behaves differently based on the URL.

The question of what effect, if any, content-disposition: attachment should have
is also raised in that bug, but this bug addresses the issue more directly. I
obviously agree with the reporter's thoughts on the subject.

I'd also like to differ with the idea that "those rfcs [1806, 2183] are to do
with mail messages". These RFCs deal with "Internet messages," specifically
"messages conforming to the MIME specifications," which is not necessarily
limited (despite the name) to "Internet mail messages." HTTP messages are not
necessarily MIME-conformant, but RFC2616 does say that "Messages are passed in a
format similar to that used by Internet mail [9] as defined by the Multipurpose
Internet Mail Extensions (MIME)," which makes it clear that the authors were
building on and borrowing from MIME. So, while there's nothing that compels
compliance with RFCs 1806 and 2183, there's nothing that forbids it, there's
sufficient common ancestry to suggest that similar behaviors are desirable.

I think the basic question hinges on 19.5.1 of RFC2616. As already noted, this
says, "If [the content-disposition: attachment] header is used in a response
with the application/octet-stream content-type, the implied suggestion is that
the user agent should not display the response, but directly enter a `save
response as...' dialog." It says nothing about handling of other content-types,
either to allow or forbid similar handling. Given the usefulness of this
approach, current practice, and the fact that this is not forbidden, it seems
desirable and reasonable to follow the same practice regardless of content-type.
This assumes, or course, that there are no clear security hazards.

Comment 19

[Boris Zbarsky [:bzbarsky]]

I was going to file this bug, based on a modified version of Rick's testcase...
:)  Good thing I found this.

This is _completely_ unrelated to bug 62760.  This bug is peculiar to multipart
streams.

Let me clarify the problem in this bug.  Say I send a multipart stream to
mozilla with three parts in it:

1) Part 1 is text/plain and says "The data is being prepared".
2) Part 2 is a text/html file that contains the data the user wants.  It has
   "Content-Disposition: attachment"
3) Part 3 is text/plain and says "The data has been sent"

Currently mozilla will not let the user view or access part 2 of the stream in a
meaningful way -- it will be replaced with part 3.  Try the url I'm setting in
the url field (old URL is "http://minutes.co.palm-beach.fl.us/minutes/ - email
for access").  See whether you can get the image.  

Now that parts of multipart streams expose content-disposition, it should be
simple to make the uriloader skip over internal viewers and just use the
exthandler....

So my suggestion is:

If the stream is an nsIMultipartStream _and_ it has a content-disposition header
_and_ the content-disposition is "attachment" _then_
nsDocumentOpenInfo::DispatchContent should do something special (not use
internal viewers and the like).

Darin?  Scott?  Bradley?  Does this seem reasonable?

Comment 20

[Darin Fisher]

sounds right to me, but how is non-multipart data handled?  does
content-disposition: attachment= override content-type even if there is an
associated viewer?

(btw: you meant nsIMultipartChannel, right?)

Comment 21

[Boris Zbarsky [:bzbarsky]]

For non-multipart data I say we just show the data.  In those cases the user can
choose to save the data via normal means ("Save" item in menu) if she so chooses.

And yes, I did mean nsIMultipartChannel.  :)

Comment 22

[Darin Fisher]

fine by me, but doesn't IE honor the content-disposition: attachment over
content-type's that it can display?  doesn't it do this to provide websites with
a programmatic way to cause a link click to result in file->SaveAs for the user?
 is this something we don't want to support?

Comment 23

[Boris Zbarsky [:bzbarsky]]

IE does honor the header (5.0 does, so I assume later ones do).  NS4 does not.

I was under the impression that you were against supporting that (comment #4). 
I think I'd suggest always supporting it, but the case for multipart streams is
a lot stronger than for top-level documents.

Also note that "honoring" the header could still mean opening it in a helper
without the user's intervention in my proposed implementation.... The user could
save it to a permanent location thence.

Comment 24

[Darin Fisher]

bz: that was pre- comment #7 and friends ;-)

Comment 25

[Boris Zbarsky [:bzbarsky]]

OK. So does the just send it over to the ExternalHelperAppService solution make
sense in general then?  If people are fine with it I'll take a shot at it.

To summarize:  If the data has "Content-Disposition: attachment", do not use any
internal viewers and pass the data on to the ExternalHelperAppService.  There
the data will get either opened in a helper application (possibly with a prompt)
or saved to disk as would normally happen for data of that type.

If this sounds wrong to you, let me know.... otherwise, I'll try to implement
something like this come next weekend.

Comment 26

[Darin Fisher]

bz: sounds good to me.

cc'ing rpotts so he can weigh in on this too.

Comment 27

[rpotts (gone)]

this sounds good to me to...

-- rick

Comment 28

[Boris Zbarsky [:bzbarsky]]

This is not going to make 0.9.9.  Targeting at 1.0 and hoping the drivers will
take this...

Comment 29

[Boris Zbarsky [:bzbarsky]]

No time to work on this for 1.0.  Adding helpwanted keyword.  If you want to
work on this, please let me know and I can give some pointers...

Comment 30

[Boris Zbarsky [:bzbarsky]]

*** Bug 141627 has been marked as a duplicate of this bug. ***

Comment 31

[Spiros Ioannou]

This seems a duplicate of http://bugzilla.mozilla.org/show_bug.cgi?id=65827

Content-type's extension gets appended to content-disposition filename.

Comment 32

[Boris Zbarsky [:bzbarsky]]

No, this is about the Content-Disposition header being completely ignored (bug
65827 is just about the filename part). 

Comment 33

[Boris Zbarsky [:bzbarsky]]

*** Bug 145024 has been marked as a duplicate of this bug. ***

Comment 34

[Boris Zbarsky [:bzbarsky]]

1.1alpha is frozen.  Unsetting milestone and will retriage in a few days when I
can make a realistic assessment of the situation.

Comment 35

[timeless]

*** Bug 152595 has been marked as a duplicate of this bug. ***

Comment 36

[Rick DeBay]

From reports 1.1 is being frozen RSN.  Any chance of this making it?

Comment 37

[Boris Zbarsky [:bzbarsky]]

None.

I _am_ aiming for 1.2alpha, hopefully....

Comment 38

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to fix this

This is not perfect, but it's as good as I can do at the moment without some
major changes to the MIME service.   The goals I had in mind were:

1)  Give the user a choice of save or launch in app
2)  Set "save" as the default choice

This patch does these.	The one thing it does not do is to properly retrieve
the helper app for a type that we handle internally (eg image/gif).  This is a
fairly small issue, imo, since most of the time this situation is encountered
the user will want to save anyway.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Attachment: Er, the real patch to fix this

Comment 40

[Boris Zbarsky [:bzbarsky]]

Attachment: same patch as diff -uw (for reviewers)

Comment 41

[Boris Zbarsky [:bzbarsky]]

Oh, that patch lays the foundation for fixing bug 58554 too.

Some URLs to test on:

http://www.zbarsky.org:8000/cgi-bin/testMultipartData.pl
http://www.zbarsky.org:8000/cgi-bin/testMultipartData2.pl
http://www.zbarsky.org:8000/cgi-bin/testContentDisp.pl
http://www.zbarsky.org:8000/cgi-bin/testContentDisp2.pl

reviews?

Comment 42

[Darin Fisher]

Comment on attachment 97300 [details] [diff] [review]
same patch as diff -uw (for reviewers)

sr=darin

Comment 43

[rpotts (gone)]

Comment on attachment 97300 [details] [diff] [review]
same patch as diff -uw (for reviewers)

r=[e-mail]

Comment 44

[Bill Law]

Comment on attachment 97300 [details] [diff] [review]
same patch as diff -uw (for reviewers)

r=law

The code looks fine.  But what's the rationale behind this bit:

+  // If we're handling an attachment we want to default to saving but
+  // always ask just in case
+  if (mHandlingAttachment) {
+    mMimeInfo->SetPreferredAction(nsIMIMEInfo::saveToDisk);
+  } else {
   mMimeInfo->GetAlwaysAskBeforeHandling(&alwaysAsk);
+  }

This appears to always force the display of the helper app dialog, even if the
user has said they don't want to see it for the MIME type in question.	Is that
a proper interpretation?  Why do we want to do that?  Maybe there's a reason,
it just isn't obvious to me.

Comment 45

[rpotts (gone)]

hey bill,

i believe the reason is security -- to prevent content from being downloaded
without the user's knowledge...

I believe that it's not always obvious that content is being downloaded...
especially with multipart/mixed content.

-- rick

Comment 46

[Rick DeBay]

If I understand what you're asking, comment #7 should answer it.  Basically,
RFCs state that attachments always require explicit user interaction.

Comment 47

[Boris Zbarsky [:bzbarsky]]

Rick and Rick are both pretty much correct.  ;)

When all's said and done, I would like to take the part where we set the
preferred action to "save" out as well...  But that would benefit from some
preliminary changes to the mime service that would allow usefully setting up a
helper for things like image/gif.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Checked in.  Everyone please get 1.2alpha once it comes out and test the heck
out of this; this is not the most robust code in the world we're touching here.  ;)

Comment 49

[Boris Zbarsky [:bzbarsky]]

*** Bug 173339 has been marked as a duplicate of this bug. ***

Comment 50

[benc]

-> filehanding per bz.