|Summary:||Filename specified in Content-Disposition header should be used as default when doing File -> Save As…|
|Product:||WebKit||Reporter:||Sveinbjorn Thordarson <sveinbt>|
|Component:||WebKit Misc.||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Enhancement||CC:||ap, cedric, groblewis, mrowe, sveinbjornt|
|OS:||OS X 10.4|
Description Sveinbjorn Thordarson 2006-03-29 18:11:29 PST
If a filename is provided for an HTML document in the Content-Disposition META tag, in the following (and correct) fashion: <meta http-equiv="Content-Disposition" content="inline; filename=myname.html"> it is completely ignored by the Safari browser when you choose "Save as..." for the page source. Instead, Safari creates its own file name from the page's TITLE attribute and appends a ".html" suffix to it. This is, I believe, a violation of the standard. At any rate, Firefox behaves correctly and respects the Content-Disposition filename. Of course, this is a trivial bug, but it would be nice to see it fixed -- especially since the fix would require very little work indeed.
Comment 1 Mark Rowe (bdash) 2006-07-02 07:11:03 PDT
Confirmed with WebKit 418.8 and the latest nightly build.
Comment 2 Sveinbjorn Thordarson 2008-05-20 06:52:43 PDT
Please correct me if I'm wrong, but this is faulty behaviour in Safari rather than in WebKit as such, right? The GUI shell around WebKit that is the Safari browser is not open source, and thus this bug could not be fixed by 3rd parties, unless I'm much mistaken.
Comment 3 Alexey Proskuryakov 2008-05-20 10:31:55 PDT
Safari doesn't look inside HTML files, so this is (at least partially) a WebKit bug. It needs to pass this information to Safari. I'm not sure if this behavior is mandated by any specifications though, and it might be dangerous to override Content-Disposition from HTML content, even if Firefox does just that. For example, a firewall may not support that, and thus be fooled about the kind of content.
Comment 4 Sveinbjorn Thordarson 2009-05-12 22:56:44 PDT
Comment 5 Mark Rowe (bdash) 2009-05-12 23:49:44 PDT
IMO this is a Safari bug, not a WebKit one. It may require a WebKit a change to expose information for Safari to use, but the problem is in Safari so this should be tracked via Radar.
Comment 6 Mark Rowe (bdash) 2009-05-12 23:52:34 PDT
Retitling to reflect the nature of the request.
Comment 8 Mark Rowe (bdash) 2009-05-13 00:15:21 PDT
Since this bug is requesting an enhancement to Safari rather than WebKit, Bugzilla is not an appropriate location to track this request. The bug has been migrated to Radar and that bug will be used by the Safari team to track the enhancement that you have requested. This Bugzilla bug will be closed as INVALID to indicate that the issue is outside of WebKit.