Correction: 

Good build: 56.0.2886.0
Bad build: 56.0.2888.0

Using the per-revision bisect providing the bisect results,
Good build:56.0.2886.0(Revision: 424099).
Bad build: 56.0.2888.0 (Revision:424625).

You are probably looking for a change made after 424587 (known good), but no later than 424588 (first known bad).

CHANGELOG URL:
-----------------   https://chromium.googlesource.com/chromium/src/+log/e9c38b3dd90ee61f9c306ba33b4a969aae10f61a..f097ee58fe6bb4c329999f03253bc4849cc50302

From the CL above, assigning the issue to the concern owner 

@lukasza - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Adding RB-Dev for this issue since it got regressed on latest M-56, Please feel free to edit if this is not the case

Thanks!

Thank you for reporting and assigning the bug to me.  I've confirmed that the bug repros on Windows at r424588 and doesn't repro one revision earlier.  I could not repro on a Linux machine.

We might have to revert the CL that triggered the regression, but I would like to try looking closer today and tomorrow in case there is an easy explanation and a fix.  Please let me know if we need to revert earlier than that.

During the repro steps, RenderFrameHostImpl::OpenURL is called with url=https://flapt.flipkart.net/click..... and with uses_post=0 and with extra_headers="Upgrade-Insecure-Requests: 1".

Able to reproduce the issue on Linux 14.04 chrome version 56.0.2888.0 as well

The automated revert doesn't apply cleanly anymore (at ).  I'll try to put together a manual revert later today.

FWIW, the OpenURL where extra_headers are non-empty is handled by the Browser::OpenURLFromTab method (and not by some more exotic content::WebContentsDelegate).

I still have no clue how / why this regression happened.  The only request with extra_headers is the https://flapt.flipkart.net/click... (the link being middle-clicked) and in Fiddler I see that the request+response don't significantly differ before and after the regression (both the initial 302 and the later /mobiles/~samsung-on8/pr?sid=tyy,4io&otracker=hp_banner_widget_0).

(ooops, pressed "Save changes" too soon - the automated revert attempt was at https://codereview.chromium.org/2419093002).

It seems that after the regression extra HTTP requests contain "Upgrade-Insecure-Headers: 1" header - it seems as if |extra_headers| are applied not only the navigation requested via NavigationController::LoadURLWithParams, but also to other requests.

I will try to investigate if we can/should remove extra headers propagation from RenderFrameImpl::willSendRequest (keeping it only in RenderFrameImpl::NavigateInternal.  This is tricky, because it seems that LoadURLParams.extra_headers should still apply after a redirect [1], but should not apply to subresources [2] (hopefully we can distinguish these cases based on webUrlRequest.getFrameType() != WebURLRequest::FrameTypeNone).

[1] - for example:
#2 0x7f8998dd6bf7 content::RenderFrameImpl::willSendRequest()
#3 0x7f898a57dc4b blink::FrameLoaderClientImpl::dispatchWillSendRequest()
#4 0x7f897d2a03d9 blink::FrameFetchContext::dispatchWillSendRequest()
#5 0x7f897c2ae9d6 blink::ResourceFetcher::willFollowRedirect()
#6 0x7f897c2c85dc blink::ResourceLoader::willFollowRedirect()
#7 0x7f899705e660 content::WebURLLoaderImpl::Context::OnReceivedRedirect()
#8 0x7f8996ff2b79 content::ResourceDispatcher::OnReceivedRedirect()

[2] - for example:
#2 0x7f8998dd6bf7 content::RenderFrameImpl::willSendRequest()
#3 0x7f898a57dc4b blink::FrameLoaderClientImpl::dispatchWillSendRequest()
#4 0x7f897d2a27a5 blink::FrameFetchContext::willStartLoadingResource()
#5 0x7f897c29fe4a blink::ResourceFetcher::requestResource()
#6 0x7f897c2c9607 blink::ScriptResource::fetch()
#7 0x7f897d2666f8 blink::DocumentLoader::startPreload()
#8 0x7f897c9017e4 blink::HTMLResourcePreloader::preload()
#9 0x7f897c98a92e blink::ResourcePreloader::takeAndPreload()

The revert has landed in https://codereview.chromium.org/2419093002 - r425473.

Hopefully this bug can be fixed when the next canary comes out (including the revert).

I've opened issue 656179 to track the problem with attaching extra_headers to non-navigational requests.  I've verified that the repro in the current bug goes away if I do not process extra_headers in RenderFrameImpl::willSendRequest if request.getFrameType() != WebURLRequest::FrameTypeNone.

r425473 was initially in 56.0.2891.0

I've tested 56.0.2891.0 (Official Build) canary (64-bit) on Windows and the problem does no longer repro.