Live view fallback with no websocket?

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

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…

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.

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).

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

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).

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]

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.

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.

Hey @chrismccord in this issue Fallback to LongPoll not working on iOS · Issue #2914 · phoenixframework/phoenix · GitHub 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.