We've decided to fix this in https://github.com/whatwg/fetch/issues/91, but not yet fixed.

See the progress of the patch at https://codereview.chromium.org/2290193003/

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

commit 5eba3e9043b40c4a0b051123a364f2c97dfdf088
Author: tyoshino <tyoshino@chromium.org>
Date: Tue Nov 08 07:55:42 2016

Make DocumentThreadableLoader's cross origin logic clearer in terms of layering

- Call removeCredentials() on ResourceRequest before invoking the
  CrossOriginPreflightResultCache's canSkipPreflight to determine the
  final request to send after possible preflight. But generate the
  referrer and origin header right before loadRequest(). It looks this
  would fix a possible bug that canSkipPreflight() always returns false
  due to setHTTPReferrer() call when m_didRedirect is true.
- Rename m_didRedirect to m_overrideReferrer as it's set only when the
  redirect was cross origin. Not always.
- Eliminate the unnecessary loadActualRequest() invocation on the path
  where we don't issue a preflight.
- Let createAccessControlPreflightRequest() just DCHECK() on the passed
  URL instead of calling removeCredentials() separately. It's better to
  just depend on the input |request| as the role of the preflight is to
  check that the |request| can be accepted by the server.

R=mkwst@chromium.org
BUG= 427429 , 641620 , 557621 

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

[modify] https://crrev.com/5eba3e9043b40c4a0b051123a364f2c97dfdf088/third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp
[modify] https://crrev.com/5eba3e9043b40c4a0b051123a364f2c97dfdf088/third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.h
[modify] https://crrev.com/5eba3e9043b40c4a0b051123a364f2c97dfdf088/third_party/WebKit/Source/core/fetch/FetchRequest.cpp
[modify] https://crrev.com/5eba3e9043b40c4a0b051123a364f2c97dfdf088/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp
[modify] https://crrev.com/5eba3e9043b40c4a0b051123a364f2c97dfdf088/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.h

This behavior is not backed by the specification. See step 11 of https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch. I think we should just get Firefox fixed here (and add a test to web-platform-tests).

I'm aware of that you've changed the step in https://github.com/whatwg/fetch/commit/eb89fcd54bb39e81b11c569f6ad7ba615883f7b9.

But sorry, I wasn't catching up with https://github.com/whatwg/fetch/issues/225 and https://github.com/whatwg/xhr/issues/31.

It seems I misunderstood what you said in https://bugs.chromium.org/p/chromium/issues/detail?id=760487#c10 when I was writing the reply https://bugs.chromium.org/p/chromium/issues/detail?id=760487#c21.

I also just learned the section "HTTP extensions" has been having texts talking about that rule since long long time ago.
https://github.com/whatwg/fetch/commit/f371e87054d9b8681ffbf10bb017cf58bcd301f8

Based on #8, it appears that the current behaviour matches the standard. As such, closing WontFix.