Bug 171239 - Content-Disposition header filename is ignored when 'download' attribute is specified in HTML
Summary: Content-Disposition header filename is ignored when 'download' attribute is s...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar, WebExposed
Depends on:
Blocks:
 
Reported: 2017-04-24 11:56 PDT by Chris Dumez
Modified: 2017-04-25 09:29 PDT (History)
8 users (show)

See Also:


Attachments
Patch (12.99 KB, patch)
2017-04-24 12:04 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (13.75 KB, patch)
2017-04-24 13:08 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (14.16 KB, patch)
2017-04-24 18:29 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews104 for mac-elcapitan-wk2 (916.60 KB, application/zip)
2017-04-24 19:44 PDT, Build Bot
no flags Details
Patch (14.16 KB, patch)
2017-04-24 19:47 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2017-04-24 11:56:48 PDT
Content-Disposition header filename is ignored when 'download' attribute is specified in HTML. This is not as per HTML specification:
- https://html.spec.whatwg.org/#as-a-download (Step 2)

Content-Disposition header filename is supposed to override the value of the download attribute.

Firefox and Chrome follow the specification.
Comment 1 Chris Dumez 2017-04-24 11:57:09 PDT
<rdar://problem/31789855>
Comment 2 Chris Dumez 2017-04-24 12:04:23 PDT
Created attachment 307993 [details]
Patch
Comment 3 Chris Dumez 2017-04-24 13:08:13 PDT
Created attachment 308001 [details]
Patch
Comment 4 Alex Christensen 2017-04-24 16:36:12 PDT
Comment on attachment 308001 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=308001&action=review

> Source/WebKit2/UIProcess/Downloads/DownloadProxy.cpp:161
> +        m_suggestedFilename = String();

Shouldn't this be response.suggestedFilename() instead of an empty String?

> LayoutTests/http/tests/download/resources/content-disposition-pass.php:2
> +header("Content-Disposition: attachment; filename=PASS.txt");

Let's do more interesting things than just all lowercase attachment and filename to test the case-insensitivity of our checks.

> LayoutTests/http/tests/security/anchor-download-allow-sameorigin.html:13
> -<a id="dl" href="/security/resources/attachment.php" download="foo.pdf">the link</a> is in the same origin.
> +<a id="dl" href="/media/resources/test.pdf" download="foo.pdf">the link</a> is in the same origin.

This change is not in the ChangeLog.  Why was it made?
Comment 5 Chris Dumez 2017-04-24 16:51:08 PDT
Comment on attachment 308001 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=308001&action=review

>> Source/WebKit2/UIProcess/Downloads/DownloadProxy.cpp:161
>> +        m_suggestedFilename = String();
> 
> Shouldn't this be response.suggestedFilename() instead of an empty String?

I do not think so. m_suggestedFilename is initialized when starting the download with the value of the download attribute. It is then used instead of the suggested filename in DownloadProxy::decideDestinationWithSuggestedFilename() if it is not null. So if I reset to null here, it means there is no override and we will end up using the resource's suggested filename in DownloadProxy::decideDestinationWithSuggestedFilename().

>> LayoutTests/http/tests/security/anchor-download-allow-sameorigin.html:13
>> +<a id="dl" href="/media/resources/test.pdf" download="foo.pdf">the link</a> is in the same origin.
> 
> This change is not in the ChangeLog.  Why was it made?

I'll add it to the Changelog. /security/resources/attachment.php was previously used from convenience but it sets a Content-Disposition header so it is no longer suitable to use for testing the download attribute.
Comment 6 Chris Dumez 2017-04-24 18:29:47 PDT
Created attachment 308036 [details]
Patch
Comment 7 Build Bot 2017-04-24 19:44:35 PDT
Comment on attachment 308036 [details]
Patch

Attachment 308036 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/3598478

New failing tests:
http/tests/download/anchor-download-attribute-content-disposition.html
Comment 8 Build Bot 2017-04-24 19:44:36 PDT
Created attachment 308048 [details]
Archive of layout-test-results from ews104 for mac-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-elcapitan-wk2  Platform: Mac OS X 10.11.6
Comment 9 Chris Dumez 2017-04-24 19:47:26 PDT
Created attachment 308049 [details]
Patch
Comment 10 Alex Christensen 2017-04-25 09:26:53 PDT
Comment on attachment 308049 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=308049&action=review

> Source/WebKit2/UIProcess/Downloads/DownloadProxy.cpp:157
> +#if !USE(NETWORK_SESSION)

Then double check that this works with network session, too, before landing.  EWS runs on El Capitan where we don't use network session
Comment 11 Chris Dumez 2017-04-25 09:28:07 PDT
(In reply to Alex Christensen from comment #10)
> Comment on attachment 308049 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=308049&action=review
> 
> > Source/WebKit2/UIProcess/Downloads/DownloadProxy.cpp:157
> > +#if !USE(NETWORK_SESSION)
> 
> Then double check that this works with network session, too, before landing.
> EWS runs on El Capitan where we don't use network session

This code is #if !USE(NETWORK_SESSION) so it is covered by EWS. Locally, I am using NETWORK_SESSION and the tests are passing (including my new one).
Comment 12 Chris Dumez 2017-04-25 09:29:30 PDT
Comment on attachment 308049 [details]
Patch

Clearing flags on attachment: 308049

Committed r215736: <http://trac.webkit.org/changeset/215736>
Comment 13 Chris Dumez 2017-04-25 09:29:32 PDT
All reviewed patches have been landed.  Closing bug.