Forums

I'm trying to use a console from behind a proxy that doesn't allow secure WebSockets, so the console falls back to using XHR. It does work intermittently, but about one out of every ten POST requests to the "xhr_send" URL will either take a very long time (>40ms) to respond or will return a 404 (or both). I don't think there's any way for me to tell whether this is due to the proxy or an actual problem on the PythonAnywhere server.

I know that you understandably prefer that people use WebSockets, but is there any way you can check the XHR side of things to see whether it's working as expected? (Or is there anyone else out there who is using consoles over XHR successfully?)

I've now tried it on my (unproxied) home connection by forcibly disabling WebSockets in Chrome, and I see the same problem with XHR whereby the HTTP requests stall or 404 some of the time, so it's not the proxy causing it. I know XHR is the second-class option but I'd be very grateful if it worked!

I've turned off websockets for myself as well to dogfood/experience it.

The console still seems pretty snappy in firefox and chromium. (ie. when I hit enter, it returns in < 1s)

When I look at the network stuff, there is a XHR POST request that is "stalled" (it is waiting for a response). Every so often, it closes with a 200 and starts a new "stalled" request. But for example, when I hit enter, the xhr post request immediately returns and a new one is generated right away.

I believe what we are seeing is just an artifact of xhr long polling though. ie. instead of holding a websocket open, instead, we hold xhr post requests open for extended periods of time.

Can you confirm if at your home connection, you are also experiencing problems in terms of slowness of the console? (in addition to network POSTs that look stalled)

I agree that during normal operation there should always be one /xhr request that is waiting for a response (the console output) while the /xhr_send requests send the console input. When there is no output the /xhr request returns after 25s and then another /xhr request is started in its place. The /xhr_send requests happen constantly while you're typing (not just when pressing enter) with each request sending one or more characters of input.

On the proxied connection there are two failure cases I'm seeing:

-An /xhr_send request returns promptly (<1s) but the polling /xhr request does not immediately return with the corresponding output. Instead the /xhr request eventually returns after >30s with code 200 but an empty response, which causes the console to reset its connection.

-An /xhr_send request takes a long time (>30s) to return but once it does return, the polling /xhr request immediately returns with the corresponding output. This doesn't make the console reset its connection but of course makes it freeze for >30s, after which it starts working again.

I believe that on my home unproxied connection the underlying problems are the same but I'll need to check again now that I understand it better. At home the symptoms are the same at least - the console sometimes resets its connection and sometimes just freezes for a while.

There do seem to be periods where it's better than others, as I was able to use the console for a few minutes this morning without it freezing/resetting but now it's regularly doing it again. Hopefully this is useful, let me know if there's anything else I can provide.

It seems to be a pattern that proxy servers that cannot pass websockets, also mess up xhr. The disconnects that you're seeing are our attempts to rebuild a working connection. I'm not sure how much we can debug a proxy that mangles our xhr requests.

I see the same problems on my unproxied home connection so it can't be caused by the proxy. I've now checked and the problems are the same as I described above - either the xhr_send request returns but then the xhr request doesn't (causing a connection reset) or xhr_send doesn't return for about a minute (causing a temporary freeze).

That's weird -- I can't see why that might work over an unproxied connection when Conrad disabled WebSockets, but doesn't when you do. How are you disabling it, exactly? Perhaps we're doing different things.