http.setTimeout called after successful 304 response #5635

Closed
lapo-luchini opened this Issue Jun 6, 2013 · 6 comments

Projects

None yet

3 participants

@lapo-luchini

https://gist.github.com/lapo-luchini/83b419666c262883fe58

% node test.js
Status: 200
Received data: 12471
% node test.js test
Status: 304
Index file is unchanged.
Connection timeout: index

When the connection is a 200 the timeout callback is not used and the program terminates immediately, when the response is a 304 the program waits for the full timeout.

AFAIR this didn't happen on node 0.6 and 0.8.

@lapo-luchini

That was on FreeBSD 8.3 / node 0.10.8, but I can confirm it on Windows XP too:

H:\>H:\d\node-0.10.5.exe test.js
Status: 200
Received data: 12471
H:\>H:\d\node-0.10.5.exe test.js a
Status: 304
Index file is unchanged.
Connection timeout: index
H:\>H:\d\node-0.8.18.exe test.js
Status: 200
Received data: 12471
H:\>H:\d\node-0.8.18.exe test.js a
Status: 304
Index file is unchanged.
H:\>H:\d\node-0.6.0.exe test.js
Status: 200
Received data: 12471
H:\>H:\d\node-0.6.0.exe test.js a
Status: 304
Index file is unchanged.
@rustyconover

If the status code is a 304 you've not setting any handlers for the response you're simply returning from the function. You need to attach a 'data' or 'end' event listener to successfully process the response. Otherwise the response remain's waiting for someone to catch its events.

@lapo-luchini

So… what you mean is that even if I don't care about the data (a 304 will most probably have an empty or default body) I should always listen in order to properly receive it?
I thought the data would be received (and 'data' events fired) even if I wasn't listening to them.

@rustyconover

No, the events aren't fired from what I understand unless they are added for HTTP responses.

It was a change in 0.10 I believe.

Adding the code makes the script work correctly.

  if (response.statusCode == 304) {
        log('Index file is unchanged.');
        response.on('data', function() {});
        response.on('end', function() {
        console.log("304 end");
        });
        return;
}
@chrisdickinson
Collaborator

This is down to changes between streams1 and 2 -- notably, streams2 won't flow data without a listener or destination pipe, so the request is just sitting there until the timeout fires. Sorry for the confusion!

@lapo-luchini

Right, thanks. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment