Thibault
Live view fallback with no websocket?
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) ?
Marked As Solved
chrismccord
It’s the same way you fallback to long polling when using channels. The LiveSocket constructor accepts the same options as Phoenix.Socket
Also Liked
chrismccord
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]
LostKobrakai
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?
florish
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.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








