[Webkit-unassigned] [Bug 175635] New: [GTK] Regression in imported/w3c/web-platform-tests/fetch/api/basic/request-headers.any.html

[bugzilla-daemon at webkit.org]

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

            Bug ID: 175635
           Summary: [GTK] Regression in
                    imported/w3c/web-platform-tests/fetch/api/basic/reques
                    t-headers.any.html
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aboya at igalia.com
                CC: lforschler at apple.com

The following layout test is failing on GTK.

imported/w3c/web-platform-tests/fetch/api/basic/request-headers.any.html

Probable cause:

r220779 introduced a workaround for the Fetch & Beacon API:

> Use "application/octet-stream" Content-Type for payloads of type
> ArrayBuffer / ArrayBufferView in Fetch & Beacon.  If we don't set a
> Content-Type header, our underlying network stack is going to add a
> "application/x-www-form-urlencoded" Content-Type header, which is worse.
> 
> Chrome is already using "application/octet-stream" Content-Type in Beacon,
> but use no Content-Type in Fetch.  The Fetch/Beacon specification says we
> should have no Content-Type header in this case but this is unfortunately not
> something we can support at the moment. Using "application/octet-stream"
> Content-Type for now seems like the lesser evil.

This workaround is unnecessary in WebKitGTK, which does not have the mentioned
limitation. The related tests were passing in WebKitGTK, but this workaround
has turned them into failures.

We should either:

a) Introduce the workaround only for platforms where it is needed.

b) Update tests expectations in all ports.

I think a) is preferrable in this case, as the workaround is for port-specific
issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170816/78a29d7d/attachment.html>