Skip to content
This repository has been archived by the owner on Oct 10, 2021. It is now read-only.

Unhandled socket hung up introduced with http-proxy #264

Open
cristiandouce opened this issue Jan 4, 2016 · 7 comments
Open

Unhandled socket hung up introduced with http-proxy #264

cristiandouce opened this issue Jan 4, 2016 · 7 comments

Comments

@cristiandouce
Copy link
Contributor

I keep getting this error code when running with [email protected] and [email protected].

>> /Users/home/test-lib/node_modules/zuul/node_modules/http-proxy/lib/http-proxy/index.js:119
>>     throw err;
>>     ^
>> 
>> Error: socket hang up
>>     at createHangUpError (_http_client.js:203:15)
>>     at Socket.socketCloseListener (_http_client.js:235:23)
>>     at emitOne (events.js:82:20)
>>     at Socket.emit (events.js:169:7)
>>     at TCP._onclose (net.js:469:12)
>> Exited with code: 1.

This doesn't happen with [email protected], before the introduction of http-proxy. If you follow the line of the thrown error:

// ../zuul/node_modules/http-proxy/lib/http-proxy/index.js:119
ProxyServer.prototype.onError = function (err) {
  //
  // Remark: Replicate node core behavior using EE3
  // so we force people to handle their own errors
  //
  if(this.listeners('error').length === 1) {
    throw err;
  }
};
@vvo
Copy link
Collaborator

vvo commented Jan 5, 2016

Yep I had seen this also, see https://github.com/defunctzombie/zuul/pull/256/files. I thought I fixed it but maybe not.

@cristiandouce
Copy link
Contributor Author

bouncy had attached a listener destroying the socket when error occurred by default. That behavior I didn't found in http-proxy module. Not sure either it's the desired behavior but at least there should be an error handler registered.

@vvo
Copy link
Collaborator

vvo commented Jan 5, 2016

but at least there should be an error handler registered.

Do you know where we should register it, or if it's an http-proxy task? Maybe there's an issue in their github

@cristiandouce
Copy link
Contributor Author

@vvo I think maybe here.
Like it's said in http-proxy code comment:

  // Remark: Replicate node core behavior using EE3
  // so we force people to handle their own errors

They expect the users of the lib to handle the errors emitted.

@vvo
Copy link
Collaborator

vvo commented Jan 8, 2016

Ok, do you think you can provide a PR to zuul to handle this?

@feross
Copy link
Collaborator

feross commented Jan 27, 2016

Hey, just saw this issue. I fixed the same issue here (webtorrent/webtorrent.io@cd4cb63) recently. Hope this helps!

@vvo
Copy link
Collaborator

vvo commented Jan 27, 2016

focusaurus added a commit to focusaurus/peterlyons.com that referenced this issue Mar 21, 2016
focusaurus added a commit to focusaurus/peterlyons.com that referenced this issue Mar 21, 2016
focusaurus added a commit to focusaurus/zuul that referenced this issue Sep 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants