Here is a snippit of the code I'll try to explain the options

```js
return fetch(t, {
   method: this.options.method,
   headers: this._prepareHeaders(e.contentType),
   body: c,
   mode: "cors",
   credentials: "same-origin",
   keepalive: this.options.isNotification
})
```

Fetch (url, options)
options: 
   method: 'GET',
   mode: 'cors',
   headers: headers
   body: body
   credentials: 'same-origin',
   keepalive: true

The headers and body are illivant to this issue. We have a logging service that sends fetch calls to our servers that need to process even if the tab/window is closed, much like the deprecated beacon API.

jbaumgardt@ Thanks for the issue.

Request you to provide us the sample test file where this issue can be reproduced, which will help in further triaging.

Thanks..

Here is a simple example. We've believe it has to do with the custom headers, the Beacon API did not custom headers, but the fetch api should. But that's just a guess.

https://jsfiddle.net/f88kjajh/3/

Thank you for providing more feedback. Adding requester "susanjunia.boorgula@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

Sorry for the inconvenience, but this is not a regression.

The keepalive flag is not yet shipped in Chrome. I guess you are enabling an experimental flag. We are about to ship the feature, but the preflight support is not included in the first release. We will fix the problem in future releases.

I do not concur. I do not have any experimental flags enabled and this only appeared once I updated to 64.

The keepalive flag mixed with the headers is causing an issue where we would like to complete fetch calls even once the window closes. We use this feature as a logging service and wish to complete those logs once a user leaves the page. A sort of logout.

We believe we might have found the source in question that was recently added it that helps

https://chromium.googlesource.com/chromium/src.git/+/9bcef7f21b943e423d91dab4104422eff753fd35%5E%21/#F24

Oops, you are right, the logic is exposed unintentionally. I will fix that ASAP. The problem will reappear when we ship the feature though.

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

commit f0a1eb5210da96ec6bd94022f36518832e673177
Author: Yutaka Hirano <yhirano@chromium.org>
Date: Wed Feb 14 05:00:07 2018

Hide RequestInit.keepalive in the experimental flag

The logic is unintentionally exposed and this CL fixes that.

Bug:  810466 
Change-Id: I46091b1ee1fb787195ca9feb7be939df1c5bc258
Reviewed-on: https://chromium-review.googlesource.com/917361
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536649}
[modify] https://crrev.com/f0a1eb5210da96ec6bd94022f36518832e673177/content/browser/renderer_host/render_process_host_browsertest.cc
[modify] https://crrev.com/f0a1eb5210da96ec6bd94022f36518832e673177/third_party/WebKit/Source/core/fetch/RequestInit.cpp

I would like to merge f0a1eb5210da96ec6bd94022f36518832e673177 to M65. The change is simple and safe to merge.

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Approving merge of CL f0a1eb5210da96ec6bd94022f36518832e673177  to M65 branch 3325 based on comment #13. Please merge ASAP. Thank you.

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

commit c78ff5bd675db5bd9b38c180e2622bed8a2cd7ce
Author: Yutaka Hirano <yhirano@chromium.org>
Date: Fri Feb 16 07:01:13 2018

Hide RequestInit.keepalive in the experimental flag

The logic is unintentionally exposed and this CL fixes that.

TBR=yhirano@chromium.org

(cherry picked from commit f0a1eb5210da96ec6bd94022f36518832e673177)

Bug:  810466 
Change-Id: I46091b1ee1fb787195ca9feb7be939df1c5bc258
Reviewed-on: https://chromium-review.googlesource.com/917361
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
Commit-Queue: Yutaka Hirano <yhirano@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#536649}
Reviewed-on: https://chromium-review.googlesource.com/923504
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#487}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/c78ff5bd675db5bd9b38c180e2622bed8a2cd7ce/content/browser/renderer_host/render_process_host_browsertest.cc
[modify] https://crrev.com/c78ff5bd675db5bd9b38c180e2622bed8a2cd7ce/third_party/WebKit/Source/core/fetch/RequestInit.cpp

I think this issue is not severe enough for stable merge.

Sorry for your inconvenience, but it will be fixed on M65. Please note that the warning will reappear in M66 as we shipped the keepalive flag without preflight support.

"Preflight request for request with keepalive specified is currently not supported"

This message still occurs on same-origin requests when custom headers are set. There should be no CORS preflight needed on same-origin requests.

We're going to support it (not very soon, sorry).

Is there an issue I can follow tracking same-origin preflights? And preflight keepalive support?