Forums

I am currently experiencing a problem with the console under Chrome -- it says it's establishing a connection, and then I can put in one or two characters before the console freezes. No more characters until it repeats the "establishing a connection" message, and then a few more characters, maybe, or not.

In general the console is for me unusable under Chrome within our network.

So I tried using IE. In this case, I get a message about was sure about displaying content, then a screen freeze for about 30 seconds. Then the "establishing a connection" message came up for the second time. Then I got a prompt. I typed "ls", got a list of a few files, and now the screen is frozen again.

30 seconds later or so, another connection message, another few characters, screen again frozen. 30 seconds later, connection message, another hundred or so characters.

If this is some new firewall interaction, it would be nice to understand it better, but it doesn't make sense that it would allow a hundred or so characters to pass every once in a while.

Any thoughts?

Best wishes,

-greg

I get the same symptoms within my work network. It's the proxy. You will need to talk to your it department to see what can be done about web sockets over https. A better solution is to just use SSH. You have a paid account, so you don't have to use the web based consoles.

Heads up: If you are in the same predicament I am you will need to reach out to the IT folks anyway even with SSH because the protocol won't reach out past an HTTP only proxy.

Yes, I agree.

I have checked outside the proxy (on my personal laptop on an unproxied guest wifi) and it works fine.

I do know that as recently as a month or two ago I was able to use this from my work computer. At this point, I can't.

I also can't use SSH from in the firewall -- that is specifically not supported.

In the past, I haven't had problems in general from https...

I think I'd probably be OK with an HTTP-only version of the console if available.

Any thoughts would be appreciated. I will also talk to our security people.

Best wishes,

-greg

For what it's worth, the security people specifically approved my use of the console screen at one point in time, so I think if I had a clear idea what to ask for I might be able to see if the situation on this end could be improved.

Thanks for your help,

-greg

I would start by talking with however is in charge of your proxy. In my case I'm in a VERY large company so it's not just stroll down the hall. Paperwork, approvals etc.

Here's a good, albeit old, article that you might pass along: http://www.infoq.com/articles/Web-Sockets-Proxy-Servers

Don't know how big your company is, but ours is around 27K employees. Pretty large.

But I do know the security people because I'm also an enterprise IT architect, so they're just down the hall a bit...

Thanks for the article!

Best wishes,

-greg

We use websockets for our console connections which make a connection from the client to the server and keep it open. It appears from the symptoms that you describe that maybe your proxy is dropping connections that are open too long.

We have code that tries websockets and that falls back to other methods that are slower. From the behaviour you're seeing, it appears to our code as if websockets are working so we use them.

So you might be able to start the conversation with your security people about whether the proxy is configured to drop long-lived connections.

Definitely a good response, and something to look into. I'll be back on that.

Well, it turns out that they did change some things about websockets in the firewall, but I can't find the people responsible for the exact change (people I talk to just know that the settings were "tweaked").

So, the question becomes: is there any way I can make this work. Perhaps degrade to another modality when it turns out that things aren't working?

Thanks for your comments...

I'm interested in alternatives as well. Right now in having to put my phone on 4g and using JuiceSSH, which works great, but certainly isn't ideal.

My first thought would be an Ajax emulator. There are a couple out there, though I honestly haven't tried any myself.

edit: ShellInABox looks promising.

Heh, we actually use a fork of ShellInABox's vt100 JavaScript widget for displaying our in-browser consoles.

I think it would be really hard for us to find a way to automatically downgrade to non-WebSockets in your situation, because as far as our code can tell, WebSockets do work -- just until the proxy cuts them off. I guess what we'd need is some kind of manual configuration to switch it off.

In the meantime... Hmm. It might be possible to disable WebSockets in Chrome with the --disable-web-sockets flag, according to this (old) Stack Overflow post.

I would be completely fine with a manual switch in the account settings or dashboard.

Unfortunately for me I am stuck using IE9 while inside the corporate network (eww I know), so even the chome switch wouldn't work for me.

Yes, I think an account setting would be nice. There are lots of people stuck behind firewalls with IE<something older> and if you'll recall, a lot of my initial enthusiasm was over how PAW lets people who are in very controlled environments have a place to explore new ideas. I think it's an important capability, so I'd like to see it on your radar, so to speak, to make sure that you can degrade with restrictions gracefully.

Of course, I'm not going anywhere, still use PAW for lots of handy things, but it was so much more handy when it was usable without dragging my laptop into work.

Thanks for your thoughts on this...

-greg

In fact, I can't use that shiny new python3.4 intallation without a working console... Oh, the irony. :-)

Um, so if you want a hacky workaround, you can:

• Open a console
• Add /frame to the end of the URL
• Load your javascript console (ctrl+shift+I)
• Enter WebSocket = undefined
• Then Anywhere.reconnect()

I appreciate that's not really a workable solution. But might tickle your curiosity...

Harry, I will definitely try that, and see what happens. At least that should isolate the problem.

Giles says: "I think it would be really hard for us to find a way to automatically downgrade to non-WebSockets in your situation, because as far as our code can tell, WebSockets do work -- just until the proxy cuts them off."

It seems to me that if you get the same console reconnecting, say, 4 or five times within 30 seconds, it might be clear that it's not working well with WebSockets.

Of course, a manual control might be the easiest and most convenient. I'd hate to give up the performance when I connect from somewhere other than my office, so I'd hope the control would be pretty convenient.

Thanks for considering it!

-greg

So I tried Harry's method above, from a location that allows WebSockets so I could compare outcomes. I agree that it may not be as performant, but it seems quite fine for casual use. I'll try it out at work next week and see if it works. It seems, though, that it would work fine. If I could select that mode somehow, I would.

By the way, the "/frame" thing is great. I wish all the consoles opened that way.

Best wishes,

-greg

I wish all the consoles opened that way.

But greg, what about our lovely logo and copyright message???

Trust me, I have them memorized.

Seriously, though, the default console experience is pretty cluttered. I recall a post a while back that showed how to open Chrome in a way that didn't intercept keystrokes. The examples made me believe that you don't look at all that decoration all that often yourselves. It is kind of cluttered.

Some word processors have a "focus mode" where they allow us to work on our content without distraction. Maybe a button to go to (and a tiny button to leave) that mode?

Small issue, though, compared to not being able to use PAW behind the firewall. More on that on Monday.

Best wishes,

-greg

Just want to mention that console behavior on various machines seems to have gotten a lot better, which makes me wonder if you've done anything to console handling, or are the firewalls I work behind being more reasonable?

Thanks for a great product...

-greg

Hi Greg -- my guess is that it must be the firewalls -- we've upgraded the performance of the console servers, but we haven't made any changes to the underlying transport.

An update on this -- we've added the option to switch off WebSockets. At the top right of every console, you'll see a checkbox. Tick it to switch off WebSockets. This will be somewhat slower, but hopefully will work from behind your firewall.

Hey, I just noticed that checkbox. That's pretty neat. I'll have to give it a try at work. Thanks!

-greg

Excellent -- looking forward to hearing how it goes!