Skip to content


Subversion checkout URL

You can clone with
Download ZIP


The secure http response never fire the end event. #728

JacksonTian opened this Issue · 26 comments
       var https = require("https");
        var options = {
            host: '',
            port: 443,
            path: '/urlshortener/v1/url',
            method: 'POST',
            headers: {
                'Content-Type': 'application/json'

        var request = https.request(options, function(response) {
            var data = '';

                data += chunk;
                // This print 
                // "kind": "urlshortener#url",
                // "id": "",
                // "longUrl": ""
            }).on('end', function (){

        request.write(JSON.stringify({"longUrl": ""}));

The nodejs version is 0.5.0pre.


I can verify this is still an issue, and would love to see a fix for it.


This seems to be a regression introduced in v0.4.8:

var https = require('https');

https.get({ host: '', path: '/accounts/o8/site-xrds?' }, function(res) {
  res.on('data', function(d) {

  res.on('end', function() {
}).on('error', function(e) {
$ /usr/local/Cellar/node/0.4.7/bin/node get.js
$ /usr/local/Cellar/node/0.4.8/bin/node get.js

See also #671.


This change seems like it may be the cause: 7c6f014

ry commented

The change is a result of 75a0cf9


I assume this still hasn't been fixed because I encountered the bug just today with the latest v.0.4.8. Does anyone have any updates on this one? I can't use 0.4.8 until its fixed. It looks like this has been an open issue for a while.


I see that 0.4.9 and 0.5.0 (unstable) have been released, but this regression is still not fixed. It would be great if fixing regressions were higher priority -- I need to stick with 0.4.7 until this is fixed.


I agree that it's annoying that it hasn't been fixed, for now I'm using this backward/forward-compatible workaround:

function done() {
  // do stuff
res.on('end', done);
res.on('close', done);

looks like still an open issue in 0.4.9


Yup, still in 0.4.9


Confirmed, this issue is present in v0.5.0


The issue seems to be specific to certain servers. In 0.4.9 it is fired with many servers, but Google is a prominent exception.


I am also experiencing this issue with Node.js 0.4.10 interacting with the Google OAuth2 API.


Seeing this occasionally with Facebook/Node v0.4.9


Seeing this occasionally node v0.4.10.
Doing 2500 https calls to amazon sqs and <10 of them close instead of end randomly.

ry commented

This isn't a bug. Responses are not guaranteed to have an 'end' event. Use 'close'.


How do you mean?
Unless something went wrong with the connection I'm expecting an end event. If the server doesn't send FIN shouldn't it timeout from inactivity rather then closing without warning?


Also, in reading

"Emitted when the underlying file descriptor has been closed. Not all streams will emit this."

As compared to

"Emitted when the stream has received an EOF (FIN in TCP terminology). Indicates that no more 'data' events will happen."

'end' sounds like the more reliable event.

The behavior is different in 0.4.7, i.e., it did what developers expected. Are you saying that was not the correct behavior?


does close get emitted when the connection is keep-alive? cause i thought that close scoped to the underlying file descriptor.


Also... as bolinfest stated you are not guaranteed to have a 'close', so you can't use it reliably either.
If you get 'end' you don't get 'close'. If you get 'close' you don't get 'end'.

Just like titanous suggested as a temporary fix you have to listen for both and double up on your callback, which is really clunky.


Should this be fixed or left as is? I noticed @ry said it wasn't a bug, but @jeffv said having both "end" and "done" were a temporary fix.

Also the issue hasn't been closed as won't fixed.

ry commented

i take back what i said before. we should probably make this work. cc @isaacs and @mikeal - this has a lot to do with stream interface.


Should one of the events be deprecated ( if so, which one) ?

I haven't looked enough at the code to understand how to properly fix the underlying events, but here is a hackish temporary fix for https.js

exports.request = function(options, cb) {
  if (options.agent === undefined) {
    options.agent = globalAgent;
  options.createConnection = createConnection;
  options.defaultPort = options.defaultPort || 443;

  var request = http.request(options, cb);
 var on = request.on; 
 request.on = function(event,listener){
    if(event === 'end'){
    }else if(event === 'close'){
    return on.on(event,listener);
  return request;


Should one of the events be deprecated ( if so, which one) ?

Yes, we need to organize this api a lot.

In my opinion, the "end" event should be guaranteed, and "close" should come afterwards as an optional "bindings are cleaned up" event.



Having had a bit of time to think on this one that's exactly what I'd hoped someone would suggest. It would be really nice if one of the events fired no matter what at the end so that if you don't really care how something terminated you can still depend on it.

If I could always bind to 'end' and not have to worry about what circumstances 'close' happens under I'd be a very happy camper. Right now I have to bind to both because sometimes the request ends and sometimes it closes and that just doesn't make sense in my mind. Those aren't mutually exclusive things in my experience. In my mind a request could close, causing it to end almost immediately afterwards. Or the request might screw up and not close properly, but it would still end. Or I can even imagine a situation where the request connection might be persistent and almost never close, but you'd still get your response and your request would still have an end.

@koichik koichik referenced this issue

streams2 #1681


Closed by de09168. Thanks for the report.

@koichik koichik closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.