Problem displaying pssh content in Firefox about ngrok HOT 15 CLOSED

This was caused by a bug in pssh's websocket implementation. I've modified ngrok with a work-around and it works now. Please confirm and I'll close this out. Thanks!

from ngrok.

@inconshreveable , that seems to work.
Thanks for the quick response and fix !

from ngrok.

@inconshreveable, I noticed that it only works in Chrome, but not in Firefox.
I see in the ngrok client UI that when using Chrome a switch of protocols occurs, but not when using Firefox.

Maybe the problem lies with the browser itself ?

Just wanted to let you know...

from ngrok.

I've only got a chromebook right now so I can't test with Firefox, can you:

1. tell me if pssh works with Firefox when not going through ngrok
2. Send me a screen capture of the raw request/response of the websocket connection that ngrok captures when using firefox

Reopening.

from ngrok.

It seems to work when not going through Firefox.
Raw request:

GET /socket?uuid=934d595c-0f92-47d1-a010-b1f67d3fd8b4&username=undefined HTTP/1.1
Host: 23401782.ngrok.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Cache-Control: no-cache
Connection: close
Cookie: _ga=GA1.2.708958845.1381761164
Origin: http://23401782.ngrok.com
Pragma: no-cache
Sec-Websocket-Key: cbC39dcuKAZxyHPrCibGPQ==
Sec-Websocket-Version: 13
Upgrade: websocket
X-Forwarded-Proto: http
X-Real-Ip: 193.58.12.29
X-Scheme: http

Raw response:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Type: text/plain
Server: thin 1.5.1 codename Straight Razor

Internal server error

from ngrok.

Perfect, thank you. There was an error in my nginx configuration about how I was handling websocket upgrade headers. Should be fixed now, can you verify?

from ngrok.

@inconshreveable, it seems to be working in Firefox now.
Thx!

from ngrok.

@inconshreveable, apologies for bugging you again but I found an issue with some further testing.
When using ngrok through command line everything seems to work.
ngrok -hostname foo.example.com 8022
ngrok -subdomain=foo 8022

But when applying this with the ngrok configuration file (~/.ngrok), it doesn't seem to work.

from ngrok.

Can you be more specific about what doesn't work?

Also, what does your config file look like?

from ngrok.

My config looks like:

auth_token: xxx
tunnels:
  pssh:
    hostname: "foo.example.com"
    auth: "user:password"
    proto:
      http: 8022
      https: 8022                                                                                                                                                                           

When using ngrok start pssh, it start the tunnel, but when browsing to the hostname, the screen is blank.

The ngrok GUI only shows the following (instead of the usual stuff like /socket etc..):

HTTP Requests                                                         
-------------                                                         

GET /                         200 OK                                  

from ngrok.

@inconshreveable what was the bug in the websocket implementation? seems if pssh has a problem better to solve it there than hack ngrok.

from ngrok.

@dieterdemeyer It's because your tunnel is using http auth. Chrome (as of version 29.0.1547.74) doesn't automatically insert http auth credentials into ws(s):// requests.You can verify this yourself by looking at the network tab of chrome dev tools and seeing the 401s come back and no authorization headers in the requests made. Here's a bug discussing it, might want to subscribe/comment: https://code.google.com/p/chromium/issues/detail?id=123862

There are comments suggesting that it works with FF, so I'd suggest that as a workaround for now.

from ngrok.

@inconshreveable , I can confirm it works with FF. I'll use that for now.
Thanks for looking into it.

from ngrok.

@kellym ngrok.com was sending all websocket requests through with a "Connection: upgrade" header instead of "Connection: Upgrade". I modified it so that the token is now sent through preserving the case made in the request.

The spec says servers must be case-insensitive though:

  A |Connection| header field that includes the token "Upgrade",
    treated as an ASCII case-insensitive value.

From here: http://tools.ietf.org/html/rfc6455

from ngrok.

Ah, I came across that case-sensitive issue too a while back. It's a bug coming from http_parser that I think is resolved now and just a matter of old dependencies in em-websocket.

from ngrok.