Leave out empty-valued Access-Control-Request-Headers: on preflights.

third_party/WebKit/LayoutTests/http/tests/fetch/script-tests/thorough/cors-preflight2.js

 if (self.importScripts) {
   importScripts('/fetch/resources/fetch-test-helpers.js');
   importScripts('/fetch/resources/thorough-util.js');
 }
 
 // Tests for CORS preflight fetch (non-simple methods).
 // Spec: https://fetch.spec.whatwg.org/#cors-preflight-fetch
 
 var TEST_TARGETS = [];
 
@@ skipping 149 matching lines @@
        '&PACAHeaders=x-servicewOrker-test&PreflightTest=200',
        [fetchRejected]],
 
       // Test request headers sent in CORS preflight requests.
       [OTHER_BASE_URL + 'mode=cors&credentials=same-origin&method=' + method +
        '&headers=CUSTOM&ACAOrigin=*&PACAOrigin=*&PACAMethods=' + method +
        '&PACAHeaders=x-serviceworker-test&PACRMethod=' + method +
        '&PACRHeaders=x-serviceworker-test&PreflightTest=200',
        [fetchResolved, noContentLength, noServerHeader, hasBody, typeCors],
        [checkMethod, hasCustomHeader]],
+
+      // Verify that Access-Control-Request-Headers: is not present in preflight
+      // if its value is the empty list - https://crbug.com/633729
+      [OTHER_BASE_URL + 'mode=cors&credentials=same-origin&method=' + method +
+       '&ACAOrigin=*&PACAOrigin=*&PACAMethods=' + method +
+       '&PACRHeaders=missing&PACRMethod=' + method + '&PreflightTest=200',
+       [fetchResolved, noContentLength, noServerHeader, hasBody, typeCors],
+       [checkMethod]],

[tyoshino (SeeGerritForStatus), 2017/01/18 06:00:29]

This test is ok to have, but what we should test is a request with a custom but
simple header, I think. Could you please add it (needs change on
getRequestInit() in thorough-util.js)?

[sof, 2017/01/18 06:26:49]

You mean explicitly furnishing the request with a significant subset of
https://fetch.spec.whatwg.org/#cors-safelisted-request-header ?

[tyoshino (SeeGerritForStatus), 2017/01/18 06:49:02]

Right. Even before this fix, we skipped the Access-Control-Request-Headers
header generation when there's no header in the ResourceRequest given to the
DocumentThreadableLoader. The problem is when there's any CORS-safelisted header
in the ResourceRequest, the Access-Control-Request-Headers header generation
code is run, and because of my patch, it skips CORS-safelisted headers to
generate an empty header. I think it's worth adding this scenario as a unit
test.

[sof, 2017/01/18 06:57:48]

ok, that code path was already being exercised by this test - i suspect some
default "CORS safelisted" headers were making it through already, but didn't
investigate which. Might as well be explicit and furnish them.

+
       // Test Access-Control-Request-Headers is sorted https://crbug.com/452391
       [OTHER_BASE_URL + 'mode=cors&credentials=same-origin&method=' + method +
        '&headers=CUSTOM2&ACAOrigin=*&PACAOrigin=*&PACAMethods=' + method +
        '&PACAHeaders=x-servicEworker-u,x-servicEworker-ua,x-servicewOrker-test,x-sErviceworker-s,x-sErviceworker-v&PACRMethod=' + method +
        '&PACRHeaders=x-serviceworker-s,x-serviceworker-test,x-serviceworker-u,x-serviceworker-ua,x-serviceworker-v&PreflightTest=200',
        [fetchResolved, noContentLength, noServerHeader, hasBody, typeCors],
        [checkMethod, hasCustomHeader2]]);
   });
 
 if (self.importScripts) {
   executeTests(TEST_TARGETS);
   done();
 }