I have run into this issue in another context. I am running Chrome 52.0.2743.116 m (64-bit)

I have an AngularJS app that is making DELETE requests to an API. CORS is enabled for this API and PUT/POST requests get the OPTIONS preflight sent out successfully and the actual request is then sent out.

When I send an OPTIONS request for DELETE the 'Access-Control-Request-Headers' header has an empty value and I get a 400 response. This is what I see in Fiddler.

REQUEST:

OPTIONS domain.com/api/path/to/delete/7/object HTTP/1.1
Host: domain.com
Connection: keep-alive
Access-Control-Request-Method: DELETE
Origin: http://localhost:55552
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Access-Control-Request-Headers: 
Accept: */*
Referer: http://localhost:55552/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8


RESPONSE:

HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/10.0
X-Frame-Options: SAMEORIGIN
Set-Cookie: ASP.NET_SessionId=blahblah; path=/; HttpOnly
Date: Mon, 12 Sep 2016 18:59:53 GMT
Content-Length: 65

{
  "message": "The collection of headers '' is not allowed."
}

I have a similar issue.
I am redirecting a XHR request from http://example.com to https://example.com.
When the browser makes the HTTPS request, it sends the header origin with value "null", which causes the backend not to send back "Access-Control-Allow-Origin".

I have this issue, too, under Chromium 53.0.2785.143 on Ubuntu 16.04.

When I send an OPTIONS request for DELETE I get a 400 response. This can be bypassed using the following flags "--disable-web-security --user-data-dir". But this is absolutely not a solution on my side.

Also, under Chrome 51.0.2704.84, I don't have this bug either.

I have the same issue.
Windows 10, Chrome 55.0.2883.87 m.

I have the same issue with chromium Version 51.0.2704.103 (64-bit) and above. 

When i have checked on browser's developer tool -> network tab -> In request headers 

Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:
Access-Control-Request-Method:POST


Empty value has been added by browser for "Access-Control-Request-Headers". This behavior is not seen for other browsers like 

Internet Explorer : version 11.0
Mozilla Firefox: version 50.1.0 

Need help for this. Any help will be really appreciated.

The empty value is aligned with the Fetch spec, https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 (step 5), but not with what CORS (previously) had (https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0)

If the spec change was intentional, needs clarification.

I suggest we change it back to what it used to be. Could you file an issue against the standard? If anyone wants to write a w3c/web-platform-tests, that would be extra great.

There are many moving parts here, but it sure looks like servers implementing CORS should gracefully handle these empty values, so thanks for considering making a change.

Filed https://github.com/whatwg/fetch/issues/459

Thanks sof for triaging.

Right. My patch https://chromium.googlesource.com/chromium/src/+/34d19ec118192003bcc041fdea30cd7650411402%5E%21/ changed the CORS logic to exclude simple headers to conform to the conclusion at https://github.com/whatwg/fetch/issues/249 ( bug 601092 ). That's the reason why it started sending the Access-Control-Request-Headers with an empty value from M52.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa

commit cf55a356c36b96ce9ee4bd6aa33235c87412a3aa
Author: sigbjornf <sigbjornf@opera.com>
Date: Wed Jan 18 08:29:58 2017

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

Following https://github.com/whatwg/fetch/issues/459 , the above
preflight header should not be included if the request following CORS
has no headers to enumerate in a preflight.

R=tyoshino,yhirano
BUG= 633729 

Review-Url: https://codereview.chromium.org/2633423003
Cr-Commit-Position: refs/heads/master@{#444303}

[modify] https://crrev.com/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa/third_party/WebKit/LayoutTests/http/tests/fetch/resources/thorough-util.js
[modify] https://crrev.com/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa/third_party/WebKit/LayoutTests/http/tests/fetch/script-tests/thorough/cors-preflight2.js
[modify] https://crrev.com/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/fetch-access-control.php
[modify] https://crrev.com/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa/third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp
[modify] https://crrev.com/cf55a356c36b96ce9ee4bd6aa33235c87412a3aa/third_party/WebKit/Source/core/fetch/CrossOriginAccessControlTest.cpp

Thanks for a fine report, equally for the confirmations by others. Apologies for having it languish on crbug for this long - back to normal now, i hope.

To get the reflected changes on Google chrome browser . Do we need to check for updates ? 

I am still facing the problem with empty "Access-Control-Request-Header" . 

Deleted: Empty_access-control-req-header.png 30.5 KB

	Empty_access-control-req-header.png 30.5 KB View Download

I'll request merging sigbjornf's fix r444303 to M56 once it's baked on canary. If accepted, the problem will go away on the next Chrome 56 stable release. If not, fix on stable release will be Chrome 57.

Change is available in releases >= 57.0.2986.0

Maybe one of you can review https://github.com/w3c/web-platform-tests/pull/4556. Those changes are testing this "regression". They cause current Chrome to fail some tests that Firefox still passes.

No new crash in DTL where the fixed function is used.

Crash query:

REGEXP(product.name, '^Chrome')
  AND REGEXP(product.version, '^57\\.0\\.2986')
  OMIT RECORD IF
    SUM(REGEXP(CrashedStackTrace.StackFrame.FunctionName, '^blink::DocumentThreadableLoader')) = 0

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#24 seems miscued and intended for issue 667254 ?

Ah, it's just FTR log that I checked that the fix hasn't caused any crash.

The more interesting question is if there will be compat issues from switching back & given that the windows canary has only been out for an hour or two, it is too early to conclude much on backporting.

Hmm, ok. Thanks for bringing up the concern.

Yeah, as

- it's been there for 52-55, developers might have changed their code to expect an empty header.
- it's not a Blink specific regression but due to the spec issue.

we should have a little longer time to see if developers are positive with the change.

Shall we target M57?

Yes, it needs to settle down a bit - all CORS changes carry some risk. i.e., if some service has been written against the (N - 1)th version of the spec here and expects A-C-R-H on all preflights, we need to give enough time for such issues to be noticed & addressed.

Targetting M57.

Thanks

I can confirm this is fixed in Chrome Canary 59.

Unfortunately I discovered that Safari has this bug. :( So I've filed a new bug on WebKit: https://bugs.webkit.org/show_bug.cgi?id=169851