Phoenix’s websocket support is via an abstraction of ‘Channels’ and phoenix does not really have any websocket helpers itself.

Rather what you want, if you want raw websockets, is just to use the cowboy API underneath Phoenix directly. Phoenix tends to not rewrite anything into itself if one of it’s dependencies already handles it, and as cowboy handles raw websockets already then it does nothing special with it, just implement cowboy’s API and put cowboy in your supervision tree, hooking in phoenix in the right place too. There are docs, hmm… somewhere on how to do it, maybe someone will link them? Hard for me to google at moment… ^.^;

Thanks mate, yes I looked at the cowboy stuff, Document use of "raw" websockets · Issue #234 · phoenixframework/phoenix · GitHub mentions dispatch_option which seems to no longer exist. The only thing I’ve found is completely hand crafting the dispatch rules which seems to be badly documented and blows up in dev as there are some secret endpoints added

Yep that’s it, and yep you have to be sure to add in Phoenix’s stuff back again, can just mostly copy/paste it’s setup code though (and add your own). ^.^;

It would be nice if Phoenix’s endpoint setup had a method to add extra things to the cowboy setup… Maybe PR it?

the problem is that approach is not working. Not all required endpoints are not documented and even searching the entire repo doesn’t show where they come from

Well what you ‘usually’ put in your application is:

      # Start the endpoint when the application starts
      supervisor(MyServerWeb.Endpoint, []),

And your Endpoint uses Phoenix’s Endpoint, so checking it’s use function is:
https://github.com/phoenixframework/phoenix/blob/v1.3.0/lib/phoenix/endpoint.ex#L440-L449

And the endpoint module behaviour defines init and other such interesting things, which delegate to the Phoenix.Endpoint.Supervisor, and here is the interesting part there:
https://github.com/phoenixframework/phoenix/blob/v1.3.0/lib/phoenix/endpoint/supervisor.ex#L65-L71

And the interesting part is probably server_children at:
https://github.com/phoenixframework/phoenix/blob/v1.3.0/lib/phoenix/endpoint/supervisor.ex#L92-L101

But it becomes hairy, so maybe wait for a Phoenix person like @chrismccord or so? ^.^;

But overall you could get the supervisor data like that then mutate it to add your own part, or maybe Phoenix has a way to add in custom cowboy handlers yet?

The cowboy handler docs allow you to set up a cowboy websocket handler to use as you see fit:

https://github.com/phoenixframework/phoenix/blob/master/lib/phoenix/endpoint/cowboy_handler.ex#L8-L52

You may have tried these docs as you said you have issues but it’s not clear what problems you’re encountering. Note the caveats in the docs where these are cow1 specific and changes here not subject to semver.

Have you tried this? This allows you to specify custom Cowboy dispatch list, and then you should be able to handle websocket connections without using the channels protocol.

Hi sorry you’re right I was really unclear about the issue. I am a bit confused myself by the whole thing

I did set up a custom dispatcher based on that docs but the moment I did the logs got spammed by errors:

18:42:19.367 [error] Ranch listener 'Elixir.CloudUiWeb.Endpoint.HTTP' terminated with reason: {{#{'__exception__' => true,'__struct__' => 'Elixir.Phoenix.Router.NoRouteError',conn => #{'__struct__' => 'Elixir.Plug.Conn',adapter => {'Elixir.Plug.Adapters.Cowboy.Conn',{http_req,#Port<0.35209>,ranch_tcp,keepalive,<0.854.0>,<<"GET">>,'HTTP/1.1',{{127,0,0,1},65375},<<"localhost">>,undefined,4000,<<"/phoenix/live_reload/socket/websocket">>,undefined,<<"vsn=2.0.0">>,undefined,[],[{<<"host">>,<<"localhost:4000">>},{<<"connection">>,<<"Upgrade">>},{<<"pragma">>,<<"no-cache">>},{<<"cache-co...">>,...},...],...}},...},...},...},...}
[info] GET /phoenix/live_reload/socket/websocket
    [debug] ** (Phoenix.Router.NoRouteError) no route found for GET /phoenix/live_reload/socket/websocket (CloudUiWeb.Router)
    (cloud_ui) lib/cloud_ui_web/router.ex:1: CloudUiWeb.Router.__match_route__/4
    (cloud_ui) lib/phoenix/router.ex:303: CloudUiWeb.Router."call (overridable 2)"/2
    (cloud_ui) lib/plug/error_handler.ex:64: CloudUiWeb.Router.call/2
    (cloud_ui) lib/cloud_ui_web/endpoint.ex:1: CloudUiWeb.Endpoint.plug_builder_call/2
    (cloud_ui) lib/plug/debugger.ex:99: CloudUiWeb.Endpoint."call (overridable 3)"/2
    (cloud_ui) lib/cloud_ui_web/endpoint.ex:1: CloudUiWeb.Endpoint.call/2
    (plug) lib/plug/adapters/cowboy/handler.ex:15: Plug.Adapters.Cowboy.Handler.upgrade/4
    (cowboy) /Users/heinz/Projects/fifo/core/cloud_ui/deps/cowboy/src/cowboy_protocol.erl:442: :cowboy_protocol.execute/4

I interpret this as the live reload server endpoint missing, I hoped the :_ case would provide that but it seems it’s not and I couldn’t figure out where in the phoenix code it was defined to add it like the /socket/websocket endpoint

Would you mind sharing in what way Phoenix interferes and breaks your code? I just saw your issue, did you get to configure it? I’m wondering so I can tackle issues down before working on this.

Going with a manual Cowboy configuration otherwise is as well a good option

Sure! This involves a bit of guess work about how phoenix works as it’s really a big black box to me.

The problem, from what I tell, is that Phoenix’s Socket will interpret any message that arrives at the Socket process and tries to handle it.

Simplified what I try to write is a websocket proxy. Data that comes from a process and gets send to the browser. Data that comes from the browser gets send to a process.

The issue start that when the process sends it data to the Socket, the socket treats it the same way it would treat websocket data, meaning it’ll start trying to apply opcodes and things to id.

So when the process sends socket_pid ! {:data, some_binary} then the socket crashes as Phoenix tries to parse that as something coming from the web socket.