Hapi: request.response should be null when response failed to transmit

[PatrickQuintal]

Hello All,

I'm trying to detect whether or not the client connection was closed or aborted prematurely. Following the Hapi documentation (As well as the previous versions) it seems to have broken in 17.2.0.

Example;

I have a route that has this handler:

handler: function(request, h) {
            console.log("request");
            return new Promise(
                (resolve, reject) => {
                    setTimeout(function() {
                        console.log("response");
                        return resolve(request.payload);
                    }, 5000);
                },
                () => {}
            );
        },

server.events.on("request", (request, event, tags) => {
        if (tags.error) {
            console.log(`Request ${event.request} error: ${event.error ? event.error.message : JSON.stringify(tags)}`);
        }
    });

server.events.on("response", request => {
        console.log(`Response sent: ${request.response}`);
    });

I also have

debug: { request: ["error"] }

set when I create the server.

Basically, to test, I made a curl request to the route and aborted it before 5 seconds.

I expected to get both an "abort" and a "close" tag for my request listener, then expected to get a null response for my "response" listener.

The results are as follows:

request
Debug: request, error, abort
Request <<id>> error: {"request":true,"error":true,"abort":true}
(5 seconds pass)
response
Response sent: [object Object]

As you can see, the response object is actually being set. Previously this was behaving correctly. I was getting an additional "closed" tag.

• node version: 8.9
• hapi version: 17.2.0
• os: Ubuntu Linux 17 (But also on a windows VM on Azure)
• any other relevant information:
  Using request.response._payload I can see that payload is "null" when I expect it to be.

However, using _payload on Azure Web App does not work correctly (request.response._payload) is always set. I would hazard a guess its due to IIS or a loadbalancer infront of the Web App.

Any suggestions?

[hueniverse]

What about this is broken? What's the actual issue here?

[kanongil]

1. No close / abort events are generated if the request is closed before the handler has finished processing.
2. request.response is not null on such response events.

[PatrickQuintal]

@hueniverse
Sorry, I should of made it more clear.
Its as @kanongil says. (Thanks)

Additionally, there is no "event.error" (Which, I recall seeing last time)

[hueniverse]

The only actual issue is that when a response is not actually transmitted, we still keep it in request.response which is a bug. Once a request has completed, request.response should only reflect what is actually sent back.

However, the previous indicators for aborted requests are going to be a bit different now. Basically, I don't see a way for an incoming request to cause a close stream error that is not also aborted. When a request has been aborted, you are getting the right logs. The additional flag is no longer set because of how the listeners are now implemented. The point is, you don't need it.

[lock[bot]]

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.