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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Feb 26 22:29:39 PST 2017


--- Comment #7 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #5)
> Comment on attachment 302784 [details]
> Patch
> 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?

I haven't looked at libsoup code, but I suspect it sanitizes platform separator, which is / in unix. We can fix libsoup if needed.

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

See the FIXME comment.

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

We don't keep the soup message in the response, we only use it to build it.

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/5190e8ed/attachment.html>

More information about the webkit-unassigned mailing list