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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=168871

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