Bug 169024 - REGRESSION(r213062): [SOUP] UTF-8 filename in Content-Disposition header incorrectly handled since r213062
Summary: REGRESSION(r213062): [SOUP] UTF-8 filename in Content-Disposition header inco...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk, LayoutTestFailure
Depends on: 169051
Blocks:
  Show dependency tree / graph
 
Reported: 2017-03-01 01:46 PST by Carlos Garcia Campos
Modified: 2017-03-02 00:58 PST (History)
9 users (show)

See Also:

Attachments
Patch (2.12 KB, patch)
2017-03-01 01:50 PST, Carlos Garcia Campos 		youennf: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2017-03-01 01:46:56 PST 
This made test http/tests/download/literal-utf-8.html to start failing. The problem is that I removed the conversion made by String::fromUTF8WithLatin1Fallback that was added in r176930. I removed it because that made fast/dom/HTMLAnchorElement/anchor-file-blob-download-includes-unicode.html to timeout.
Comment 1 Carlos Garcia Campos 2017-03-01 01:50:26 PST 
Created attachment 303055 [details]
Patch
Comment 2 Michael Catanzaro 2017-03-01 06:42:43 PST 
Comment on attachment 303055 [details]
Patch

I don't understand it. You convert the header from UTF-8 to the internal encoding (UTF-16)... but only if it's ASCII...?
Comment 3 Carlos Garcia Campos 2017-03-01 09:12:18 PST 
(In reply to comment #2)
> Comment on attachment 303055 [details]
> Patch
> 
> I don't understand it. You convert the header from UTF-8 to the internal
> encoding (UTF-16)... but only if it's ASCII...?

In r176930 ResourseResponse was changes to not apply any encoding conversion from message headers when adding them to the header map. So, we create the String with String constructor no String__fromaUTF8() so that we don't actually make any charset conversion. The header could be either utf8 or latin1, so we try to convert to utf8, only when it's not, falling back to latin1 if the conversion fails.
Comment 4 Carlos Garcia Campos 2017-03-01 09:38:21 PST 
Committed r213226: <http://trac.webkit.org/changeset/213226>
Comment 5 WebKit Commit Bot 2017-03-01 12:57:17 PST 
Re-opened since this is blocked by bug 169051
Comment 6 Carlos Garcia Campos 2017-03-02 00:58:17 PST 
Committed r213273: <http://trac.webkit.org/changeset/213273>