[Webkit-unassigned] [Bug 168871] [GTK] Downloads attributes tests are failing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Feb 26 16:14:32 PST 2017


--- Comment #5 from Chris Dumez <cdumez at apple.com> ---
Comment on attachment 302784
  --> https://bugs.webkit.org/attachment.cgi?id=302784

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

> LayoutTests/platform/gtk/fast/dom/HTMLAnchorElement/anchor-file-blob-download-includes-slashes-expected.txt:2
> +Downloading URL with suggested filename "test2\abe.png"

Seems unfortunate that backslash is not sanitized but I guess you guys do not have to worry about Windows?

>> Source/WebCore/ChangeLog:9
>> +        filenameFromHTTPContentDisposition().
> What is buggy about it? Shouldn't we fix that bug, especially if it's affecting all ports? It sounds like it requires a adding FIXME at least?
> I'd rather use libsoup to get the filename *inside* the implementation of filenameFromHTTPContentDisposition if need be. Avoiding use of filenameFromHTTPContentDisposition feels like a workaround.

Is it buggy or does it just not sanitize? For what it is worth, on mac and iOS, we also let CFNetwork deal with this. CFNetwork takes care of sanitizing for us and it has the benefit of being consistent between the 2 code paths: regular content disposition header & download attribute.

> Source/WebCore/platform/network/soup/ResourceResponseSoup.cpp:99
> +    SoupMessageHeaders* soupHeaders = soup_message_headers_new(SOUP_MESSAGE_HEADERS_RESPONSE);

Not familiar with the GTK code base but why do you need to create your own soup headers? Cannot you just get the ones of the underlying soup response?

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170227/4a0eac30/attachment.html>

More information about the webkit-unassigned mailing list