Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.1.11 caused fatal error: socket hang up #70

Open
asujata opened this issue Aug 26, 2014 · 24 comments
Open

0.1.11 caused fatal error: socket hang up #70

asujata opened this issue Aug 26, 2014 · 24 comments

Comments

@asujata
Copy link

asujata commented Aug 26, 2014

The latest update to 0.1.11 caused my existing proxy setup to fail with "fatal error: socket hang up".

My setup:

proxies: [
          {
            context: '/api',
            host: '...',
            port: 443,
            https: true,
            changeOrigin: true,
            xforward: false,
            rejectUnauthorized: false
          }
        ]

The error only occured when trying to use https.

Switching back to 0.1.10 resolved my issue.

@lukeman
Copy link

lukeman commented Aug 27, 2014

Same bug hit me. As soon as SSL comes into play connections fail. Pinning to 0.1.10 still works.

@rpocklin
Copy link

Ouch! Same problem, glad there's a workaround.

@zhukov
Copy link

zhukov commented Sep 3, 2014

Same for me. I see the request response in browser, but nginx says that there was a plain request over SSL port.
Downgrading to 0.1.10 with npm install [email protected] solved the problem.

@zourtney
Copy link

zourtney commented Sep 3, 2014

I just encountered this same error...and burned quite a bit of time tracking it down! Downgrading to 0.1.10 worked for me as well.

@ghost
Copy link

ghost commented Sep 4, 2014

Had the same error, after debugging forever - downgraded to v0.1.10 :(

@lostthetrail
Copy link

Also experiencing this. Downgrading to 0.1.10

@seglo
Copy link

seglo commented Sep 29, 2014

I believe it has something to do with the upgrade to the 1.x.x branch of http-proxy. grunt-connect-proxy 0.1.10 is using "http-proxy": "~0.10.3". There's a lot of rewritten work in the 1.x.x branch so it's hard to be any more specific on what the cause might be.

@seglo
Copy link

seglo commented Oct 2, 2014

I've resolved this issue in my own plugin (grunt-connect-prism) by handling the new error event in http-proxy 1.x.x. I was able to reproduce the bug using a user's codebase, but I haven't figured out how to write a test for it. If someone using grunt-connect-proxy who can reliably reproduce this issue wants to try out my fork and confirm whether or not it works for them, then I'll submit a PR.

seglo@7badde7

Read more about the error handler on http-proxy issue tracker.

http-party/node-http-proxy#527

@rbrcurtis
Copy link

@seglo sadly your fork doesn't work for me.

@seglo
Copy link

seglo commented Oct 7, 2014

@rbrcurtis Thanks for trying. Is your project on github or can you provide me with a reliable way of reproducing the issue?

@rbrcurtis
Copy link

Its not unfortunately (work project). Its not doing anything special
though; your fix handles the errors but what I think might be happening is
that grunt-connect-proxy isn’t handling ssl on the target correctly.

I’ll dig into it more tomorrow when I have time and if I can’t figure it
out I’ll work up an example project for you.

On Tue, Oct 7, 2014 at 3:24 PM, Sean Glover [email protected]
wrote:

@rbrcurtis https://github.com/rbrcurtis Thanks for trying. Is your
project on github or can you provide me with a reliable way of reproducing
the issue?


Reply to this email directly or view it on GitHub
#70 (comment)
.

@seglo
Copy link

seglo commented Oct 8, 2014

@rbrcurtis Is the server you're proxying using HTTPS? I think grunt-connect-proxy is incorrectly mapping the https option to the secure option in node-http-proxy. The secure option isn't used to determine if the target is https, it's used to determine whether to validate certs or not. If your https is self-signed try setting this to https to false.

https://github.com/nodejitsu/node-http-proxy#options

@rbrcurtis
Copy link

my local server is not https, but the remote servers I’m proxying to are
all https. They’re all on amazon and are not self signed. I tried setting
https to false and still get socket errors on latest and
{"error":"proxy_error","reason":"read ECONNRESET”} on your fork.

On Wed, Oct 8, 2014 at 10:49 AM, Sean Glover [email protected]
wrote:

@rbrcurtis https://github.com/rbrcurtis Is the server you're proxying
using HTTPS? I think grunt-connect-proxy is incorrectly mapping the https
option to the secure option in node-http-proxy. The secure option isn't
used to determine if the target is https, it's used to determine whether to
validate certs or not. If your https is self-signed try setting this to
https to false.

https://github.com/nodejitsu/node-http-proxy#options


Reply to this email directly or view it on GitHub
#70 (comment)
.

@jox
Copy link

jox commented Nov 4, 2014

We're having the "Fatal error: socket hang up" on some rest api that runs on port 8080 with "https: false". Strangely it helps to change the api and proxy settings to another port (e.g. 8082).

Another phenomenon is that some in our team are having this issue and some not. I myself never had it until today. Now I also changed the port to 8082 and it works again.

We're using grunt-connect-proxy 0.1.11.

@ciglesiasweb
Copy link

I have the same situation as jox.
Fortunatelly I realize the day before I installed express for testing purposes and that destroyed my workspace.
The solution was: unistalling node and reinstall...

@procyborg
Copy link

absolutely. reverting to 0.1.10 suppresses the socket-hangup bug. i am proxying a https endpoint for oauth2.
thanks for the pointer guys.

@ihr
Copy link

ihr commented Feb 5, 2015

I can confirm that changing the port worked for me. Here is relevant part of my Gruntfile.js:

proxies: [
                {
                    context: ['/api'],
                    host: 'localhost',
                    port: 8090,
                    https: false,
                    rewrite: {
                        '^/api': ''
                    }
                }
            ]

@bostrom
Copy link

bostrom commented Feb 6, 2015

I'm having a problem with secure WebSocket connections over the proxy (HTTPS->HTTP). Normal websocket connections work fine in my app. So I thought I'd debug the wss case and wrote a WebSocket test for it. I decided to go simple and started off with just normal ws:// connections.

However, even that didn't work since I got slapped in the face by this "fatal error: socket hang up" bug, so now I'm stuck with no working websocket connections over the proxy whatsoever (even though they work in my browser). Changing ports doesn't seem to work and in 0.1.10 the tests won't even run. I've tried to dig in to http-proxy also, but to no avail.

The branch with the websocket test is here https://github.com/Flexim/grunt-connect-proxy/tree/wss if you're interested in debugging it with me.

@xiaoshao
Copy link

I have the same problem in 0.1.11. I have two proxies as follows.
{ context: '/google', host: 'google.com', port: '80', rewrite: { '^/google': '', } }, { context: '/baidu', host: 'baidu.com', port: '80', rewrite: { '^/baidu': '/', } }
the proxy for google works well. but the proxy for baidu doesn't work.

@ianblenke
Copy link

I'm having the same "Fatal error: socket hang up" problem with https proxy. Using http works just fine. Reverting to 0.1.10 doesn't seem to help. Would love to turn up the debugging here to understand what the problem may be. Any hints as to how to accomplish that?

@ianblenke
Copy link

Correction: reverting to 0.1.10 did work, I had to clean out the newer node_modules version first.

@dzdrazil
Copy link

I'm also having this problem on 0.2.0 (win8, node 0.12.2); reverting to 0.1.10 did work for me as well.

@lostthetrail
Copy link

I confirm this is still happening on 0.2.0

@mteodori
Copy link

same issue here, and the servers I am proxying to have valid certificates, not self-signed ones, the only solution is to stick to [email protected] and block it via npm shrinkwrap --dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests