Three tests are failing on Windows now, perhaps this is related to the openssl upgrade or perhaps something that's changed in libuv, I don't have good enough data to say yet. My guess is openssl because of the recent upgrade.

• test-https-foafssl
• test-tls-securepair-server
• test-tls-server-verify

Each of these uses openssl-cli.exe s_client ... via a spawn() and then interacts with stdin to do some funky stuff with a local server and verifies stdout. It's as if stdin isn't being properly flushed to the client.

This is the basic pattern, extracted from test-https-foafssl:

  var args = ['s_client',
              '-quiet',
              '-connect', '127.0.0.1:' + common.PORT,
              '-cert', join(common.fixturesDir, 'foafssl.crt'),
              '-key', join(common.fixturesDir, 'foafssl.key')];

  var client = spawn(common.opensslCli, args)

  client.stdout.on('data', function(data) {
    // .. verify and clean up
  });

  client.stdin.write('GET /\n\n');

It just hangs and the tests end up timing out. When you do an 'inherit' for stderr on the spawn you can see that it initializes but doesn't react to the client.stdin.write() at all.

Then, if you do a full 'inherit' and skip the rest of the steps and take control of it:

  var args = ['s_client',
              '-quiet',
              '-connect', '127.0.0.1:' + common.PORT,
              '-cert', join(common.fixturesDir, 'foafssl.crt'),
              '-key', join(common.fixturesDir, 'foafssl.key')];

  var client = spawn(common.opensslCli, args, { stdio: 'inherit' })
  return

And manually type in GET /\n\n to the console it does what it's supposed to; connecting to the local server and printing out the response.

I've tried putting a timeout on the write, I've tried using full CRLF, nothing works and I don't know why taking the parent process stdin should be any different than simulating stdin data.

Anyone?