Allow HTTPS long poll requests

[dahjelle]

This is a possible fix for outmoded/discuss#395, where longpoll HTTPS requests were getting cancelled before the timeout value passed to server.stop().

Fair warning: I'm not very familiar with Hapi internals nor low-level Node HTTP & socket handling, so I don't have any idea if this fix is appropriate. Any and all suggestions—or a complete rewrite!—more than welcome! My real goal is simply to get this particular issue fixed in whatever manner is fastest. :-D

Issue Description

Expected behavior

server.stop({timeout}, callback) should wait for the provided timeout before forcibly closing any pending requests.

Observed behavior

For HTTPS requests only, server.stop immediately forcibly closes pending requests, without waiting for either a response to the request or for the timeout.

Analysis

It looks like connection.js looks for the _isHapiProcessing flag. However, in an HTTPS connection, that flag is undefined.

I think what is happening is that the _dispatch function sets the flag on a TLSSocket instance. But, by the time we are handling the stop in the _stop function, we no longer have access to the TLSSocket, but rather have just a Socket.

(As far as I can tell, a TLSSocket is created from a Socket originally? as some sort of wrapper?)

It appears that we can set the flag on the socket by using the _parent property of a TLSsocket. It's private and undocumented, so I hope there is a better way to do this, but that's all I could find.

[devinivy]

Good find– for TLS I think we should be listening for secureConnection rather than connection in order to track the same connection/socket that appears on req.

[dahjelle]

@devinivy Interesting! I'm not clear where you mean, though…in the _dispatch function? in the _stop function? Thanks…I'm still quite unfamiliar with this particular code. :-D

[devinivy]

I mean in connection.js, where connections are added to this._connections. See around line 155. It's sort of a bummer for us that TLS and non-TLS have slightly different APIs, since for the most part hapi is able to cater to "the standard HTTP API", which might include other servers like node-spdy, node-http2, etc. I'm wondering if simply listening for both events will be okay, or if the connection event actually needs to be ignored when using TLS. I suppose that's okay, as the docs instruct one to set the tls server option to true even when using a custom listener over TLS. Hopefully someone else can weigh-in here, or further investigate.

@dahjelle while it's not my decision and I think that your fix works, I'm guessing hapi wont take this particular fix because it relies on the undocumented _parent field, just as you said. So I'm trying to think of some other solutions! Thank you for bringing it up and providing a solution– it definitely illuminates the problem at hand!

[dahjelle]

I'm guessing hapi wont take this particular fix because it relies on the undocumented _parent field, just as you said.

Definitely makes sense! My objective was to clearly communicate the issue as much as anything—I figured that actually fixing it was rather out of the scope of my expertise. :-)

I'm wondering if simply listening for both events will be okay, or if the connection event actually needs to be ignored when using TLS. I suppose that's okay, as the docs instruct one to set the tls server option to true even when using a custom listener over TLS. Hopefully someone else can weigh-in here, or further investigate.

I tried replacing

        this.listener.on('connection', this._onConnection);

in line 155 with

        if (this.settings.tls) {
            this.listener.on('secureConnection', this._onConnection);
        }
        else {
            this.listener.on('connection', this._onConnection);
        }

(…and then the matching set of code down in _stop for removing the listeners.)

While my new test passes just fine that way, it causes another test failure:

Failed tests:

  100) Connection _stop() waits to stop until all connections are closed (HTTPS):

      actual expected

      02

      Expected 0 to equal specified value

      at /…/hapi/test/connection.js:625:95

…which I haven't dug into yet.

Hopefully someone else can weigh-in here, or further investigate.

Hopefully! :-)

[dahjelle]

I think there is more subtlety here than I'm figuring out. :-/

[dahjelle]

The way this test is written doesn't take into account the handshake that happens before the secureConnection event is fired. I removed this part of the test to account for that—is that a correct way to fix it?

[devinivy]

Try the following,

                const socket1 = new Net.Socket();
                const socket2 = new Net.Socket();
                socket1.on('error', () => { });
                socket2.on('error', () => { });

                socket1.connect(server.info.port, '127.0.0.1');
                socket2.connect(server.info.port, '127.0.0.1');

                TLS.connect({ socket: socket1, rejectUnauthorized: false }, () => {

                    TLS.connect({ socket: socket2, rejectUnauthorized: false }, () => {

                        server.listener.getConnections((err, count1) => {

                            expect(err).to.not.exist();
                            expect(count1).to.equal(2);
                            expect(Object.keys(server.connections[0]._connections).length).to.equal(2);
                            // ...

[devinivy]

You should actually create the socket and TLS.connect() one at a time to be safe (rather than creating/connecting both at the same time then calling TLS.connect() in series).

[devinivy]

Might look like,

                const socket1 = new Net.Socket();
                const socket2 = new Net.Socket();
                socket1.on('error', () => { });
                socket2.on('error', () => { });

                socket1.connect(server.info.port, '127.0.0.1');
                TLS.connect({ socket: socket1, rejectUnauthorized: false }, () => {

                    socket2.connect(server.info.port, '127.0.0.1');
                    TLS.connect({ socket: socket2, rejectUnauthorized: false }, () => {

                        server.listener.getConnections((err, count1) => {

                            expect(err).to.not.exist();
                            expect(count1).to.equal(2);
                            expect(Object.keys(server.connections[0]._connections).length).to.equal(2);

[dahjelle]

Awesome, thanks!

[dahjelle]

I pushed up new changes using listening for either secureConnection or connection depending on whether this.settings.tls is true or not. I had to adjust one of the existing tests to take into account the fact that secureConnection doesn't fire until after TLS handshaking is done…please feel free to make suggestions.

Otherwise, this PR gets away from using the private _parent property, and still fixes the issue I had.

Comments/suggestions very welcome!

[dahjelle]

Thanks for your comments, @devinivy ! I adjusted the PR.

[dahjelle]

What's next for this PR? Further suggestions?

[devinivy]

Looks good to me. Want to get @hueniverse's impression. I would be curious now if today's HTTP2 implementations use the secureConnection event (as they ought to).

[AdriVanHoudt]

@devinivy let me /cc @jasnell to answer that since he is working on the http2 implementation

[dahjelle]

This patch seems to be working for us in production for the past week or so, for whatever that's worth.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.