User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 Try clicking on the supplied link: http://www.netbeans.org/issues/showattachment.cgi?attach_id=8339&file=NBSplash_3_4_1.gif This is an attachment to an Issuezilla (derived from Bugzilla) report. This version of Issuezilla has been patched to send a header including: Content-disposition: attachment; filename=NBSplash_3_4_1.gif Content-Type: image/gif; name=NBSplash_3_4_1.gif When I click on it in Moz 1.2.1, I get a dialog with the options: 1. Open using an application (GIF image: image/gif) [Choose...] 2. Save this file to disk Both of which are fine, but what I really wanted was to just view the image! This was originally reported in the NetBeans website issue-tracking system: http://www.netbeans.org/issues/show_bug.cgi?id=29561 However I believe that the server behavior here is reasonable. The server does not know and cannot reasonably know which MIME types the browser is capable of displaying directly and appropriately. Also, in the majority of cases, the user does in fact wish to save the attachment to disk, and in this case it is desirable for the server to supply an appropriate filename (based on the filename used when originally uploading the attachment). So the server sends what I think is the correct set of headers. Yet for the user to actually view the GIF in Mozilla, it is necessary to save the file to disk (/tmp, say), copying the filename in the Save dialog, then jump to the URL field, and type in "file:///tmp/", press Ctrl-V, enter. Annoying. http://bugzilla.mozilla.org/show_bug.cgi?id=98360#c38 seems to provide the explanation (if I understand correctly): "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." Most of the time, but the behavior is annoying the rest of the time, when the user just wants to look at the sent file directly in the browser. This would apply to images, text, HTML, etc. I suggest that if "attachment" is given as the content disposition for a link which is clicked, where the content type is one that can be displayed directly in Mozilla (either natively like HTML or via plug-in like PDF), that a dialog be shown (as RFC #2183 seems to require) as now, but that there be three options: 1. Open using an application (GIF image: image/gif) [Choose...] 2. Save this file to disk 3. View in Mozilla where #3 would behave as if you had just clicked on a plain link with no Content-Disposition header at all (i.e. file is not saved except perhaps to cache, opens in current window or tab, etc.). Reproducible: Always Steps to Reproduce: 1. Click on link: http://www.netbeans.org/issues/showattachment.cgi?attach_id=8339&file=NBSplash_3_4_1.gif Actual Results: Dialog pops up which permits GIF to be opened with a helper app, or saved to disk. Expected Results: Dialog pops up which permits GIF to be opened with a helper app, or saved to disk, or viewed directly.
> The server does not know and cannot reasonably know which MIME > types the browser is capable of displaying directly and appropriately. Yes, it can. It's called the "Accept: " header. I suggest patching IssueZilla to make use of it and cease to send "Content-Disposition: Attachment" for MIME-types explicitly listed in the Accept: header, rather than insisting that Mozilla do an end run around this (mis)use of HTTP.
Just as a quick hint, I _would_ like to add a "view in browser" option to that dialog, and whether content-disposition is set should be irrelevant to offering that option. Adding this function just requires a pretty comprehensive rewrite of how we do helper apps (and possibly chunks of the uriloader), is all. Note that in IE the header you are sending will cause a filepicker to come up, so the _only_ thing the user will be able to do is save to disk.... So you have a problem no matter what. If all you want is to suggest a filename, just do: Content-disposition: inline; filename="whatever" and the browser will show the content inline if possible, putting up that same dialog if not possible. In either case, attempting to save will use the filename from the header.
Thanks to both of you for the comments! To Christopher: true, I had thought of that, but wasn't sure how well it would work. Given this header: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 what should the server conclude? This version of Mozilla will display image/gif inline just fine (even if it is only "20% preferred") but will not display application/lala inline (though it is "10% preferred"). The header correctly indicates that image/png is preferred to image/gif; it does not indicate that both are natively displayable. To Boris: thanks for the tip re. Content-disposition: inline; filename="whatever" which I confirmed works exactly as desired in my copy of Mozilla at least. I will reopen the request for our version of Issuezilla to use this header - feel free to close this issue as WONTFIX unless you still think it would be nice to offer a "view inline" option on the save dialog anyway. I don't have a copy of IE to test with. M$ discontinued their Unix version, looks like, and my XP partition is quite busted. :-/
hmm.. i'm thinking WONTFIX since mozilla is behaving as expected when a Content-disposition: attachment; response header appears. is there really any value in changing our behavior? will users really care?
> unless you still think it would be nice to offer a "view inline" option on > the save dialog anyway I do think it would be nice, but that's already covered by another bug (with many dups). Which I can't find at the moment.
*** Bug 187549 has been marked as a duplicate of this bug. ***
Related: bug #171296
Is RFC2616 the right place to look? In section 19.5.1 about Content-disposition, there isn't mentioned 'inline' as a disposition-type. Couldn't the following paragraph be interpreted as if 'attachment's are shown like inline if they are not application/octet-stream: "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." So Mozilla seems to be more consistent, but http-services not violating RFC2616 by using 'attachment' just to give a name (like 'inline') have a problem.
Yes, but "what does IE do?"
Nobody seems to have mentioned this, but this problem didn't exist in 1.2 and earlier. It becomes a very big problem if you are a person that frequents web-based forums based on software like vbportal or phpbb. One such forum is located at vpforums.com. Virtually every post in some topics contain attached screenshots. In 1.2 and earlier I can just click and view them - No muss no fuss. Going to 1.3 or later, the forum becomes completely unusable since you get prompted on every click, and there's no option for "use Mozilla's internal gif/jpeg viewer". If there were, I'd set that and check the "do not ask" box.
> Nobody seems to have mentioned this, but this problem didn't exist in 1.2 and > earlier. We didn't support content-disposition:attachment very well back then. > One such forum is located at vpforums.com. That's vbulletin. They're purposefully sending a content-disposition header that is malformed in such a way that IE treats it as "inline" and any browser that follows the spec treats it as "attachment". Their newest version is fixed to just use "inline"; I suggest you contact the forum operator and ask him to upgrade. None of which affects this bug, of course. We all agree this needs fixing. Want to do it? I can point you to the code...
*** Bug 208639 has been marked as a duplicate of this bug. ***
Having read all these comments, I cannot work out what the bug is. Is it that we want an option to view inline things that are marked as being attachments? Mozilla needs a general "override server mime type, treat this file as _foo_" option somewhere, just to handle the numerous misconfigured servers. Would this just fall under that?
hixie: Yes, your first paragraph is what this bug is about, as I understand it. I don't think it would fall under the second thing - that second suggestion would probably only be usable if the file is being displayed in a browser window, right? But disposition:attachment files are never shown there, all the user sees for them is a dialog telling them they should save the file or open them with another app.
Yeah, I guess it would be covered by: 1. This bug, which is about adding "( ) Open in Mozilla" to the download dialog. 2. Adding an option somewhere that overrides Mozilla's current determination of the MIME type for the currently opened file. 3. Adding an option in the normal "unrecognised type" download dialog for doing the equivalent of 2 but when the file wants to be downloaded, not opened. I hate the idea of adding all this UI though, especially for a feature that will be understood by even fewer people than the character encoding menu.
*** Bug 208697 has been marked as a duplicate of this bug. ***
*** Bug 166393 has been marked as a duplicate of this bug. ***
I think that this should be marked as a bug, not an enhancement. Section 15.5 states very clearly that Content-Disposition is not part of HTTP, but it is described since so many people (incorrectly) implement it. Section 19.5.1 then goes on to say that if a UA is going to implement it, that it should only be used as a suggestion for the file name. So, the only time that this header should have any bearing is when a user decides that they want to save a page element (or requests an object that has a content-type that we don't decode,) and then only to suggest a file name.
14 years ago
Created attachment 137245 [details] [diff] [review] Example of new prefs to disable force-external of attachment. First off, this patch is only intended to be a demo of how I dealt with the issue here. It modifies the nsDocumentOpenInfo::DispatchContent to check for a preference when forceExternal would be set true. It checks for 3 prefs, based on the mime type: network.attachment.force-external.general/specific network.attachment.force-external.general/* network.attachment.force-external.*/* If a pref is found, then its value is used for forceExternal instead of 'true'. This is particularly useful if you're stuck on some annoying webmail system which insists on sending "Content-Disposition: attachment" for inline images. Obviously, I'd rather fix the webmail system; but as I can't get at that, I can hack mozilla instead. (Maybe not well, but hey, gotta start somewhere.)
why not modify the helper app dialog to show a "View in Browser" option? (like the patch in bug 57342 does)
*** Bug 229785 has been marked as a duplicate of this bug. ***
14 years ago
*** Bug 192704 has been marked as a duplicate of this bug. ***
sorry to cc spam. I've just been hoping for this for so long.
*** Bug 251215 has been marked as a duplicate of this bug. ***
not a networking issue
Created attachment 161817 [details] [diff] [review] patch provide an option to view it with browser. I just add a few lines to make browser open the file after it has been downloaded to the tmp directory.
Comment on attachment 161817 [details] [diff] [review] patch bz, can you help me to review the patch? Thanks in advance.
Comment on attachment 161817 [details] [diff] [review] patch >Index: uriloader/exthandler/nsMIMEInfoImpl.cpp >+ urlString.AssignWithConversion(url.get()); This breaks for non-ASCII URIs. >+ return watcher->OpenWindow(nsnull, >+ "chrome://navigator/content/navigator.xul", "_blank", This introduces a dependency from this code (which is core code) to the exact embedding app (SeaMonkey). For example, this will not work with Firefox. Nor with other embedding apps. That's not acceptable. Further, for cases when this is content we actually _can't_ view, this will lead to an infinite loop of browser windows. Finally, this will open a new window for some reason. We really want to just load the data in the window where it started to load (so session history and the like is preserved). biesi mentioned a patch earlier in this bug that does something like this, no?
(In reply to comment #29) > >+ urlString.AssignWithConversion(url.get()); > This breaks for non-ASCII URIs. It works fine with a URI having Chinese characters and XRemoteService.cpp does the same thing: http://lxr.mozilla.org/seamonkey/source/xpfe/components/xremote/src/XRemoteService.cpp#792 > This introduces a dependency from this code (which is core code) to the exact > embedding app (SeaMonkey). For example, this will not work with Firefox. Nor > with other embedding apps. That's not acceptable. I can change that to use the preference value of "browser. chromeURL". > Further, for cases when this is content we actually _can't_ view, this will > lead to an infinite loop of browser windows. do you have any advise on how to avoid it? > Finally, this will open a new window for some reason. We really want to just > load the data in the window where it started to load (so session history and > the like is preserved). I think as far as we respect the content-disposition and treat it as an attachment, it could not be so unacceptable as to download it and view it in a new brower window. Is that right?
Comment on attachment 161817 [details] [diff] [review] patch a slightly better way to go if you want to take this route is probably to get the nsIRefreshURI off the window context and setup a refresh uri using that; that way, the url will be loaded in the current window this patch needs to modify pref-applications-edit.xul as well (iirc that's the name) uris are utf-8. do NOT use AssignWithConversion for them; use CopyUTF8toUTF16. "Open in Browser" should only be shown if the browser can actually handle the file. not sure what a good way to detect this is, though... I suppose I'm not totally against this approach. I fear this might cause a correctness issue though, where we try to load the local file with a wrong mime type (i.e. one different from the one sent by the server). all in all, I prefer the patch I mentioned somewhere above...
(In reply to comment #30) > and XRemoteService.cpp does the same thing: > http://lxr.mozilla.org/seamonkey/source/xpfe/components/xremote/src/XRemoteService.cpp#792 this doesn't mean it's a good thing... note that AssignWithConversion is deprecated. I'm working on removing it from the mozilla code.
(In reply to comment #31) > all in all, I prefer the patch I mentioned somewhere above... I have looked at your patch in bug 57342 and I think it can solve more problems than mine. I will stop updating my patch. Hope that patch could be checked in soon.
*** Bug 264493 has been marked as a duplicate of this bug. ***
Why is it marked as "enhancement"? Not being able to open web pages / images in the browser window is a bug, even if this is under particular conditions (e.g. when non-standard HTTP headers are used).
*** Bug 274265 has been marked as a duplicate of this bug. ***
For some reason Windows Media Player playlist's (.asx) requires the "Content-Disposition: attachment" be included in the headers sent from a php script, or the player replies with "The source filter for this file could not be loaded". The error occurs with either no content-disposition or content-disposition: inline. Thus, there does not appear to be any way to open a dynamic playlist (php) stream for asx files without asking each time what to do with the file, as the browser ignores the 'do this automatically'.
Discussion trend so far worries me. Remapping mime-types, new dialogue options are well and good but not on target for this bug. If you get to the dialogue, its already too late. Comment #19 hit the nail on the head: Using disposition attachment in the Browser to trigger the dialogue in fact is *not* standards compliant at all. Simply disable handling of disposition=attachment for the Browser: behave as-if it were inline, as older mozilla (1.1? and earlier) and Communicator 4.x did. Should be by default but can be a user pref if you insist. Of course don't interfere with Save-As and Save-Link-As. Of course still offer the dialogue if mime-type is not handled by any of: internal, registered plugins, registered helper. Would I say No to precision control for specific mime-types? Absolutely, unless it still offered: global disable option first, followed by options to white-list specific few types for which to enable the "attachment" (dialogue) behavior. Not that relevant here but currently arguing with server folk who are sending PDF's with "attachment" who believe their server is not misconfigured and say: "You get the dialogue with option to launch the helper, so what's the problem?" Answer: It defeats tabbed-browsing, it defeats byte-serving, it defeats "#anchorName" for targets within the PDF, wastes a second external acroread process... In other words it strips all benefits of PDF, dumbing it down to the level of PostScript.
I fully agree with comment #38 and #19. An option in the about:config list to turn off content-disposition would be fantastic.
Another testcase is http://www.groenlinks.nl/2ekamer/notities/Notitie.2005-09-20.1114/publication/download_file (an HTML file this time!). We would like to see this fixed for embedded as well; Epiphany displays the same problem.
*** Bug 315736 has been marked as a duplicate of this bug. ***
*** Bug 186236 has been marked as a duplicate of this bug. ***
This behavior is just wrong. A plain-text email should not include any file with a content disposition of inline, even if it's another text file. If thunderbird wishes to include files as inline, then it needs to support drag-n-drop on any of those platforms. I attached an html file to a plain-text email, and it included it as 'inline'!
See discussion about security considerations starting at bug 57342 comment 159.
(In reply to comment #161 of bug 57342) > Content-disposition is described in http://www.faqs.org/rfcs/rfc2183. This is a RFC about E-mail messages, not HTTP headers. So, it doesn't apply directly to HTTP (see below). > It is also mentioned in the "Security considerations" section of the > HTTP spec (http://www.faqs.org/rfcs/rfc2616), although it's not clear > what security considerations it's talking about. The security consideration is about the directory path information. See Section 19.5.1: The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only. Indeed, taking into account the directory path information would be a security hole: for Unix, imagine that the filename-param is "../.profile" and that the user's download directory is just under his $HOME. Then, note that this header is non-standard in HTTP. But Section 19.5.1 describes how it can be implemented and particularly says that the goal is to provide a *default filename* (comments #8 and #19 recalled that). It 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. Note the "if". This doesn't say that the user agent should propose a dialog; this just says that when the user does a "Save As", a default filename is suggested (and this is only a suggestion). Well, there's an exception (and it doesn't depend on whether the content disposition is "inline" or "attachment"): 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. But anyway, proposing this dialog also makes sense when there are no Content-Disposition headers, since the contents can't be displayed. The HTTP/1.1 RFC does not say that a difference between the "inline" and "attachment" dispositions should be made. And even if one wants to make a difference in a web browser, then it should be the following. First read http://www.faqs.org/rfcs/rfc1806.html Section 2.2: 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. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. If one wants to transpose that ("their display should not be automatic" but the user can view them with an action, such as a click) to a web browser such as Firefox: * For elements img and object, the user would need to click on the link so that the corresponding image or object could be displayed (but this behavior would still be optional, since non-standard). * For element a, the contents of the document at the given URL is never display automatically; the user needs to click (or do some other action) to follow the URL. So, in this case, the "attachment" disposition shouldn't change anything. IMHO, this clearly shows that the current behavior of Firefox, i.e. not showing the contents of the URL (if in a supported media type) when the user requests it, is buggy. Even with a MUA, it is possible to view an attachment (in addition to be able to save it). Based on this analysis, I suggest that the severity should be increased from "enhancement" to "normal" (or even "major" since this bug may prevent from viewing some sites that use the Content-Disposition header in a perfectly documented manner).
Which bug broke the old behavior of "View Image"? I think "View Image" is either now working like "Load/Reload Image" or not at all. "View Image" should allow one to view just that image in the current window, or if middle clicked, in a new window, as it used to be. A new option should be created for loading/reloading an image in the current page, and that other option needs left alone. It would say "Load Image" if the image didn't initially load, and "Reload Image" if the image did load. Please refer me to the right bug report if this one isn't it. I searched all over for bugs regarding "View Image", and found very few possibly relevant bugs.
I apologize for any ambiguity in the previous message. It looks as if "View Image" is in fact just broken (just for me, or not, I am not sure). "Show Image" is in fact a separate option. If there is a bug report for "View Image" being broken, please refer me in that direction. If this is the one, then thanks.
One can hack the binary executable, void your warranty: locate appropriate occurrence of "Content-disposition" string, deliberately and very carefully respell it without length change of string or file, and suffer side-effects like no longer seeing filename option that rides in same header. Could an extension (or yuck a proxy) edit/filter response-headers on-the-fly in time to usefully address this?
Following the answer to my bug report in Debian, FYI, the current Firefox behavior is covered by the recent draft (first version on 2010-08-30): http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03 (note: this is just a draft). It says: If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user to save the response locally, rather than process it normally (as per its media type). Personally I find this rather annoying that web sites force me to do things I do not want, in particular when I've entered the URL in the address bar, and at least the choice should be offered to the user. I event think that user agents should be able to ignore "attachment" completely (i.e. treat "attachment" as "inline").
The important thing is to treat the content as unique origin (ie. no origin).
I agree with that IETF draft: Content-disposition being "attachment" vs "inline" lets the server suggest the default action. Thus, having the dialog pop up is fine. But, not allowing content types that Firefox can handle (text/plain, image/png, etc) is to be viewed directly is a clear-out bug. Dancing through hoops like saving the file to some random place then opening it manually is a ridiculous workaround. The dialog already has "open with XXX", "open with YYY", "save as"; it's a matter of adding "open with Firefox". Since there is a checkbox to do that automatically on all future files, a separate config option as suggested in #39 would be redundant if we got that.
(In reply to Robin Lu from comment #30) > > Finally, this will open a new window for some reason. We really want to just > > load the data in the window where it started to load (so session history and > > the like is preserved). > I think as far as we respect the content-disposition and treat it as an > attachment, it could not be so unacceptable as to download it and view it in > a > new brower window. Is that right? For me, this would not be acceptable. Please see this request : https://bugzilla.mozilla.org/show_bug.cgi?id=801786
I started thinking about how I would prefer this be handled, and this is what I came up with. 1. Create error/info pages for cases where Firefox receives a response with a type it has no mechanism display in its own tab or where a response cannot be displayed because the content does not match the type, include information about the type and disposition, include buttons to invoke part 2 (including use defaults without prompt) and part 3 (including reversion without prompt), include buttons to open files this content was saved to by part 2 in helper apps. 2. Replace the current Save As dialog box (which at least on Mac OS is a separate window that can get lost behind everything) with a tab-bound sheet, add an option to go back one stop in session history if saving succeeds, add options to control automatic invocation of Save As and automatic saving on similar future responses, add a button to invoke part 3. Saving content to which part 1 applies adds a button to the page described in part 1. 3. Add a "Reinterpret Content" sheet to change the effective type used to render the contents of the current tab (without reloading) or to select a helper when opening from part 1, include interpretation choice which always invokes part 1, include option to open Save As after reinterpreting, include options to automatically reinterpret similar future responses, include options to revert a changed interpretation of the current tab to either the default or the result of applicable automation rules. 4. Revise handling of request responses to honor the automation options in parts 2 and 3. I think the current behavior would make a reasonable default. This automation does not apply to navigation within the session history (e.g. with back or forward buttons), only to new responses. This way, every link adds a page to the session history, the page associated with a downloaded file has a button to open that file in the helper app, and a Save As prompt can't get lost behind other windows. The rules for automatic invocation of Save As and automatic saving wouldn't need to change much, but should give the user explicit control of how(/if) that behavior is affected by a disposition header. The rules for automatic reinterpretation might be difficult to get right, but could initially be a simple list of from→to pairs that gets checked before any rendering or saving is done. There is a funny case where a response could be automatically saved and then rendered in the tab without mentioning the save to the user; that could be prohibited, or handled by a notification bar. Most comments in favor seem to want part 2 without part 1, which might be easier to implement, but I think it's more natural to put something in the session history for every request and keep external actions external. Part 3 is really more bug 57342, so I'll mention this comment there too.