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

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

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

darin

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.

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.

marking INVALID

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.

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?

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.

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?

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

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)

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

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

This bug maight be tightly connected to bug 62760

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.

mscott: what is your feeling on this?

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.

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?

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?)

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

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?

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.

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

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.

bz: sounds good to me. cc'ing rpotts so he can weigh in on this too.

this sounds good to me to... -- rick

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

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

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

This seems a duplicate of http://bugzilla.mozilla.org/show_bug.cgi?id=65827 Content-type's extension gets appended to content-disposition filename.

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

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

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

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

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

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

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.

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 on attachment 97300 [details] [diff] [review] same patch as diff -uw (for reviewers) sr=darin

Comment on attachment 97300 [details] [diff] [review] same patch as diff -uw (for reviewers) r=rpotts@netscape.com

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.

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

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

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.

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

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

-> filehanding per bz.