Cypress: Unexpected http requests after the browser window opens

[bjowes]

Current behavior:

When I click a specfile in the Cypress GUI and the browser window opens, Cypress emits three odd http requests. The requests are directed to random hostnames.

Typical case:

• http://nxixipcfj/
• http://jgdgrlnncg/
• http://uxucserkokwfr/

I noticed this since I am developing an authentication plugin which acts as a proxy in front of Cypress.

The behavior appears with Chrome (after running 'cypress open') but not in headless mode.

The tests proceed and run as expected. I simply find that this may indicate a larger issue in the root cause for the odd requests.

Desired behavior:

No odd http requests after Chrome browser launch

Steps to reproduce: (app code and test code)

1. Set environment variable HTTP_PROXY to your proxy address (to catch the odd http requests)
2. Start Cypress using 'cypress open'.
3. Start any specfile. The example specfiles included with Cypress also triggers the issue.

Versions

Cypress: 3.1.3 and 3.1.4
Mac OS X 10.14.2
Chrome 71

[flotwig]

Hey Björn, thanks for reporting this.

It looks like this is a behavior we've inherited from Google Chrome. Chrome makes three requests to random fake domains at startup to detect DNS hijacking by the ISP, so that it can adjust Omnibox behavior for the user.

According to a discussion on the Chromium bugtracker, --disable-background-networking will disable this behavior.

However, that flag also disables some other functionality within Chrome. It's referenced 16 times throughout the codebase. We'll need to assess if this impacts any functionality we're using before we can turn it on for users.

[flotwig]

Looks like background networking WAS disabled at one point, but it was re-enabled after it started causing issues with tests: #1320

[brian-mann]

This is correct. I disabled it after it caused bizarre network hangs in chrome under certain circumstances where the window was not focused. It may have been a bug in chromium now fixed.

[bjowes]

Thanks for really fast feedback @flotwig and @brian-mann !

Since you have identified that this is expected behavior in Chrome, from my perspective it is fine to leave it be. Better for Chrome to behave as close to real conditions as possible during the tests.

I will see a few odd requests in my plugin debug logs, but that is acceptable when I know where they are coming from.

[bjowes]

I've coded a small condition to check for the Chrome startup requests. If anyone else stumbles on this it may come in handy. It is hooked onto the error event of my proxys request to the host. req refers to the original incoming request to the proxy.

if (req.method === 'HEAD' &&
  req.url === '/' &&
  req.headers.host.indexOf('.') === -1 &&
  req.headers.host.indexOf(':') === -1 &&
  req.headers.host.indexOf('/') === -1 &&
  errno === 'ENOTFOUND') {
  debug('Chrome startup request connection error, ignoring');
}

[flotwig]

To see if this is still happening, I pushed up a test commit with --disable-background-networking re-enabled and re-ran the tests a bunch of times in CI. Here are the results:

https://circleci.com/gh/cypress-io/cypress/tree/issue-3151

There was only 1 failure out of all those re-runs, and that failure doesn't look like it was caused by a timeout within Chromium. @brian-mann does this look like an improvement over the behavior you were seeing in #1320? Or was it more sporadic than this?

[jennifer-shehane]

@flotwig What is the status of this issue?

[flotwig]

Won't fix, I think. Brian and I talked about it and although it looks like the issue hasn't cropped up in the test runs I did, the benefits of allowing background networking vs the potential consequences of disabling it again are small.