Live view fallback with no websocket?

Phoenix Forum Questions / Help
, ,
1

Hi,

I used liveviews for a website. Everything works fine and the technology is really great. But I’m running into troubles with some customers behind proxy that won’t let websockets through properly.
With regular websockets, I have the option to enable longpolling for them. Is there a way to enable longpolling for live view too as a fallback (with a heavy performance hit, I’m aware, but better than nothing at all) ?

1 Like
2

It’s the same way you fallback to long polling when using channels. The LiveSocket constructor accepts the same options as Phoenix.Socket

5 Likes
3

Indeed, I tried passing the longpolling parameter and it works in my dev environment (using Firefox and disabling the websocket with dev tools to test). Thanks !
But it does not work in production, it seems the fallback does not occur and the websocket keeps trying to connect. Maybe it’s because the server is behind HAProxy (yes, proxy on server side and proxy on client side, the joy of corporate environments). I will try to check with the hosting team.
My next option is to enable SSL to force the proxy to leave the websocket alone.
I’m marking your answer as a solution, since it works with normal cases…

4

Hi @Thibault, I ran into this forum thread while investigating a seemingly similar issue with LiveView websockets not connecting specifically in corporate remote desktop environments.

I know it’s been a while since your last post, but did you have any luck finding a solution?

For reference for people googling for specific HTTP response codes in combination with LiveView: In our case, the websocket connection setup seems to get stuck after a HTTP 426 (Upgrade Required) response somewhere in the initial connection process.

5

Sadly no. It was in a corporate environment (banking) and they felt that they could not secure web sockets in a satisfying manner. So any websocket was blocked by their corporate proxy and nothing to be done.
So I had to retrofit the application back to REST and vanilla JS. Thankfully that was actually surprisingly fast to do, by turning the live view into regular templated and sending responses as plain HTML over REST.
Live view is a marvelous technology, however adoption remain a problem with some companies that still live in the years 2000 (well, they dropped IE6 support at least).

3 Likes
6

Were you unable to get live view to work via HTTP long polling?

7

Nope didn’t work either, everything went through a proxy and it did not seem to agree with long polling. And working from the outside made debugging extremely frustrating. Since it was a small project, it was faster to fall back to REST/HTML than to try to find a solution (when you’re start involving corporate IT in a bank, time starts counting in months).

1 Like
8

The long poll transport is only Ajax so if REST/HTML works, then long poll will work. Did you make the following changes to your app.js and endpoint?

import {Socket, LongPoll} from "phoenix"

let csrfToken = document.querySelector("meta[name='csrf-token']").getAttribute("content")
let liveSocket = new LiveSocket("/live", Socket, {
  transport: LongPoll,
  params: {_csrf_token: csrfToken}
})

…

  socket "/live", Phoenix.LiveView.Socket,
    longpoll: [connect_info: [session: @session_options], log: false],
    websocket: [connect_info: [session: @session_options], log: false]
8 Likes
9

I did make some tries with long polling and it did not seem to work.
But as I said, it’s pretty difficult to take in this kind of environment : I had no direct access to the production server, no access to the client network. This made testing an pretty frustrating process. So I must admit that I switched to plan B pretty quick in order not to lose too much money on the project.
I will test it again in this context if I have the opportunity to use if for a larger project.

1 Like
10

Thanks for the detailed response!

Just to be sure: that JavaScript snippet, should I be able to find that in the LiveView and/or Phoenix.Socket documentation? I’m pretty sure I wouldn’t have added that as part of enabling long polling if I hadn’t read this forum thread.

11

Hey @chrismccord in this issue https://github.com/phoenixframework/phoenix/issues/2914#issuecomment-398111457 you sketched out a solution for falling back to long polling if the websocket cannot connect. Have you seen a similar mechanism one could write for this in live view? The linked solution involves writing callbacks to channel functions that you don’t have available to you in LV.

12

You can ditch the channel function, that was really to show where to initialize your app code. So all you need to do is check if you have yet to establish a connection on socket.onError, then disconnect and instantiate a new LiveSocket with the long poll transport.

2 Likes
13

I’m finding that disconnecting is not doing what I’d like. The socket initially created still attempts to reconnect even after calling disconnect until it reaches its maximum retry count.

14

I got curious how socket.io handles the issue and I found this information:

Since Socket.IO 1.x, the fallback algorithm changed from a downgrade approach to an upgrade approach.

Long polling pretty much works everywhere, so that is used at first so you can get a “connection” right away. Then in the background, an attempt is made to upgrade the long polling connection to a websocket connection. If the upgrade is successful, the long polling stops and the session switches to the websocket connection. If it’s not successful, the long polling “connection” stays open and continues to be used.

I’m wondering if something like that would be possible in phoenix?

6 Likes
15

Perhaps the concern there is latency? You effectively double the time required to have a working websocket connection.

1 Like
16

To follow up on my own post: we tried to fix the issue by enabling longpoll transport as a fallback (Elixir side). This did not fix the connection issue for our customers in their Citrix environment. We then did what @chrismccord suggested in post #8 (making longpoll the default and disabling websockets). This did the trick.

Given the above, I think I can conclude that in our case, the fallback mechanism did not do anything somehow. Haven’t had the opportunity to assess why (hard to do as we are not able to reproduce the error locally), but if Citrix disables websocket connections somewhere on the network level, I can imagine that this is an unhandled case, as the fallback mechanism may be based on a browser not supporting websockets.

If anyone has ideas on how to get to the root of this, I’d love to help, but I’m afraid I need some initial pointers to get started.

4 Likes
17

Yes, this was my problem. Browser worked fine, but the client (bank, they tend to be paranoid) infrastructure involved proxies that blocked any websocket. So this was blocked at the network level too and fallback was not applied.
I don’t think this is a rare use case in big companies.

2 Likes
18

To be clear, the “fallback” only happens if window.WebSocket is undefined. Transport fallback after trying websockets must be user implemented. As you so also, you can hardcode the transport.

3 Likes