The problem is that after willSendRequest callback changes the request, the load is cancelled while transitioning to committed state. This happens because the load is not waiting for the response policy check, so it continues and when transitioning to committed, FrameLoader::closeURL() invalidates the current policy check that causes a load failure. The new request returned by the API doesn't have any requester, so it's no longer considered a main resource load. In the network process the resource load task doesn't wait for the response policy and continues the load, sending the data to the web process. Once the first data is received the load transitions to commit, but the response policy check is still ongoing. This can only happen when using the C API (I don't know about the Cocoa API), but not with the GLib API because it doesn't allow to create a new request, only to modify the passed in one. With the C API we loss other internal things of the request like the priority, but I guess the most important one is the requester.
Created attachment 337153 [details] Patch
Comment on attachment 337153 [details] Patch We should probably run that API test on Mac, too.
(In reply to Alex Christensen from comment #2) > Comment on attachment 337153 [details] > Patch > > We should probably run that API test on Mac, too. Right now, I believe we have a bunch of cross-platform API tests that are run only with XCode, when most of them should really be run on all ports. I did not realize that the reverse was true as well. It would be good to comprehensively improve this situation.
(In reply to Alex Christensen from comment #2) > Comment on attachment 337153 [details] > Patch > > We should probably run that API test on Mac, too. Indeed, I was surprised it was still prefixed WebKit2, then I realized it was because it's not run in Mac. We should rename it and add it to xcode in a follow up, but I prefer if someone with a mac can do it, it's painful process for me.
Committed r230298: <https://trac.webkit.org/changeset/230298>
<rdar://problem/39202609>