NPNProtocols docs need clarification / example

[coolaj86]

@indutny The documentation on the HTTPS page refers to the TLS page which fails to give an example (obviously 'hello' and 'world' are not true internet protocols).

I'm assuming that it should be something like this:

https.createServer({
  key: fs.readFileSync(path.join(certsPath, 'my-server.key.pem'))
, cert: fs.readFileSync(path.join(certsPath, 'my-server.crt.pem'))
, ca: [
    fs.readFileSync(path.join(caCertsPath, 'intermediate.crt.pem'))
  , fs.readFileSync(path.join(caCertsPath, 'root.crt.pem'))
  ]

  , NPNProtocols: ['http/2.0', 'spdy', 'http/1.1', 'http/1.0']

});

But I'm not sure if 'http/2.0' is a valid option or how I would pass off http/2.0 requests to the http/2.0 handler, etc (I'm assuming that no http2 module has yet to make it into core yet).

[Fishrock123]

cc @shigeki also

[Fishrock123]

But, io.js does not support http2 at the current time.

[indutny]

Ok, it does work this way. But it does nothing but just supply the extension in the ServerHello/ClientHello. So there is no underlying protocol implementation, and the user is supposed to check the selected protocol with socket.npnProtocol to figure out what protocol should be used.

So, to restate, no implementation other than http/1.1 is provided. This is how I handle this in node-spdy: https://github.com/indutny/node-spdy/blob/master/lib/spdy/server.js#L236-L240

[indutny]

But I'm open to suggestions on how it could be improved! :)

[tellnes]

I'm going a little bit of topic and answer to how this can be improved.

What about splitting the secureConnection into multiple events based on protocol. Eg.

server.on('http/1.1', fn)
server.on('spdy', fn)

If we also changes the current http implementation to only listen on http/1.1 and http/1.0, then implementing extra protocols in user land would be as easy as adding an extra event listener.

If this gets positive feedback, I'll open a pull request.

[shigeki]

@tellnes Does your change have any difference with the below?

var server = https.createServer(opts);
server.removeAllListeners('secureConnection');
server.on('secureConnection', function(s) {
  this.emit(s.npnProtocol, s);
});
server.on('http/1.1', function(s) {
  http._connectionListener.call(this, s);
});

If it is the same, I think it is very easy to implement in userland.

[tellnes]

@shigeki Yes, that's basically my proposal. But your solution is not foolproof. What if another library already has added another listener to secureConnection?

I think we should try to make an api where this monkey patching of the server object which all those libraries are doing is unnecessary. Referencing #1101 here.

Here is a code example to iterate on.

var server = http.createServer(opts);
require('http2').attach(server)
var wss = require('ws').attach(server)

server.listen({ port: 80 })
server.listen({ port: 443, tls: true, http2: true, cert: '...', key: '...' })

server.on('request', function(req, res) {
  /* incoming request which is either
     - http
     - https
     - http2
  */
})

wss.on('connection', function () {
  // new websocket connection
})

I also think we should expose an api for easily pushing extra protocols as long as it is done before the listen method is called.

Also, are not npn going to be replaced with alpn and we will need to expose a similar api for that?

But if we are not doing something like this, then we should mark http._connectionListener as public, so we can bless that the way to do this is like @shigeki example above. Also maybe remove the underscore in the name before documenting it and deprecate the underscored version.

[indutny]

I'm with @shigeki here, it is really simple to implement and is only a matter of a couple of lines of code. Emitting random-named events on the server seems to be a bad idea to me, especially considering that the user may supply any protocol name to the NPN. Even secureConnection ;)

[tellnes]

@indutny your last argument convinces me also that that was a bad ide.

What about doing something like this in lib/https.js:

function(socket) {
  if (socket.npnProtocol === 'http/1.1' ||
      socket.npnProtocol === 'http/1.0' ||
      socket.npnProtocol === false)
    return http._connectionListener.call(this, socket);

  if (EventEmitter.listenerCount(this, 'secureConnection') !== 1)
    socket.destroy();
}

[indutny]

Hm... this might be the thing. What do you think about making it more generic, though? I have done that _connectionListener wrapping a couple of times in 3rd party libraries, and it will be quite interesting to explore a generic way of doing it.

Like supplying a function preconnection or something like this that will decide whether the default https listener should be called, or the custom one.

[tellnes]

I've done the same wrapping a couple of times myself, so I'm also interested in making it more generic.

If we are not going for some kind of events, I think the solution above is the best one. That will let you add multiple secureConnection listeners and they will only need one if to see if the connection is for them.

The only extra code an app implementor then will need is something like this:

var protocols = [ 'h2', 'http/1.1', 'http/1.0' ]
server.on('secureConnection', function(socket) {
  if (!~protocols.indexOf(socket.npnProtocol)
    socket.destroy()
})

Maybe we can implement the above with some kind of option?