This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-26
Channels
- # announcements (10)
- # asami (15)
- # babashka (200)
- # beginners (48)
- # calva (56)
- # cider (6)
- # clara (2)
- # cljs-dev (18)
- # cljsrn (6)
- # clojars (3)
- # clojure (23)
- # clojure-czech (2)
- # clojure-europe (41)
- # clojure-germany (5)
- # clojure-italy (19)
- # clojure-nl (5)
- # clojure-uk (8)
- # clojurescript (60)
- # clojureverse-ops (5)
- # cursive (14)
- # datomic (6)
- # events (1)
- # figwheel-main (5)
- # graalvm (17)
- # honeysql (2)
- # instaparse (1)
- # integrant (9)
- # jobs (5)
- # music (2)
- # off-topic (37)
- # other-languages (1)
- # pathom (10)
- # proletarian (5)
- # quil (3)
- # reagent (39)
- # reitit (4)
- # remote-jobs (3)
- # reveal (6)
- # rum (9)
- # shadow-cljs (27)
- # vrac (3)
- # xtdb (5)
so I had the semi-bright idea of using caddy as a proxy in dev, given how easy it makes TLS for local development. I’ve got it going fine for my http-kit ring server (reverse-proxying HTTPS 8443 -> HTTP 8080). I also have a websocket passing successfully through Caddy to my ring server (<wss://127.0.0.1:8443>). Figwheel’s giving me trouble though. If I reverse-proxy HTTPS 9501 -> HTTP 9500 and set :connect-url to <wss://127.0.0.1:9501>, the default server in Figwheel seems to respond to <wss://127.0.0.1:9501> with a 200 and the default HTML page that Figwheel sends out when you don’t have /resources/public/index.html
for it to latch on to.
:connect-url "
DOES work … I had left off the trailing figwheel-connect
and was trying to connect to the root /
route with a websocket, which is already taken by the default host page that boots the figwheel connection :man-facepalming: .