In https://codereview.chromium.org/2380773002 I'm looking to check whether a navigation received response headers, so we can ignore navigations that received headers but did not commit, such as 204 responses. The page load metrics code wants to ignore aborted navigations that didn't commit if they have headers associated, as we interpret this as an indication that the abort was actually an internally generated abort, such as for a 204 or download, rather than a user-initiated abort.

My new tests to detect that we properly handle 204s and downloads pass by default, but fail when --enable-browser-side-navigation is passed on the command line.

It appears that there are two different codepaths for setting the HTTP response headers on a NavigationHandle, and the browser-side path is not invoked consistently.

Response headers are set in NavigationHandleImpl::WillProcessResponse.

For non-browser-side navigation, the code path is:
 NavigationResourceThrottle::WillProcessResponse
 WillProcessResponseOnUIThread
 NavigationHandleImpl::WillProcessResponse

For browser-side navigation, the code path is:
 NavigationResourceHandler::OnResponseStarted
 NavigationURLLoaderImplCore::NotifyResponseStarted
 NavigationURLLoaderImpl::NotifyResponseStarted
 NavigationRequest::OnResponseStarted
 NavigationHandleImpl::WillProcessResponse

While the non-browser-side path consistently invokes NavigationHandleImpl::WillProcessResponse and thus provides response headers to the NavigationHandle, the browser-side path aborts before calling NavigationHandleImpl::WillProcessResponse in some cases, causing the availability of response headers to be inconsistent.

In particular, the browser-side path aborts early for downloads. In NavigationResourceHandler::OnResponseStarted we have the code:

  if (info->IsDownload())
    return true;

which aborts the rest of the call path and prevents headers from being provided to the navhandle.


Later, in NavigationRequest::OnResponseStarted, we have code to abort early for 204 responses:
  // HTTP 204 (No Content) and HTTP 205 (Reset Content) responses should not
  // commit; they leave the frame showing the previous page.
  DCHECK(response);
  if (response->head.headers.get() &&
      (response->head.headers->response_code() == 204 ||
       response->head.headers->response_code() == 205)) {
    frame_tree_node_->ResetNavigationRequest(false);
    return;
  }

which prevents headers from being provided to the navhandle.

It seems that we should consistently provide response headers to navigation handles in these cases, so implementers of WebContentsObserver::DidFinishNavigation can determine if a navigation that did not commit and has a net error code of aborted have headers associated or not, like in my case, so they can better understand the cause of the abort.

For now, I'm going to add my new tests to testing/buildbot/filters/browser-side-navigation.linux.browser_tests.filter - they can be removed after this bug is fixed.