feat(ingestor): document and test ws:// / wss:// WebSocket MQTT broker support#902
feat(ingestor): document and test ws:// / wss:// WebSocket MQTT broker support#902emuehlstein wants to merge 1 commit intoKpa-clawbot:masterfrom
Conversation
…port
paho.mqtt.golang v1.5.0 already supports WebSocket MQTT connections natively
via gorilla/websocket. The ws:// and wss:// URL schemes pass through
ResolvedSources() unchanged — no scheme translation needed.
Changes:
- config.go: clarify ResolvedSources() scheme mapping in godoc comment;
ws:// and wss:// explicitly noted as pass-through
- main.go: extend TLS config to cover wss:// (same system-CA-pool tls.Config{}
already applied for ssl://); fixes missing TLS setup for WebSocket TLS
- config_test.go: add TestResolvedSourcesSchemeMapping (ws/wss/tcp/ssl/mqtt/mqtts
all schemes) and TestLoadConfigWSSource (wss:// round-trip with auth)
- config.example.json: add wsmqtt example source showing ws:// / wss:// usage
with username/password; update _comment_mqttSources to list all schemes
Tested with the meshcore-mqtt-broker WebSocket proxy running behind Caddy TLS.
|
testing at scope.chicagooffline and dev-scope.chicagooffline.com |
Expert review on PR #902SummaryGood PR — documents a real undocumented capability and closes a real TLS gap for BLOCKER (2)1. Merge conflict: 2. Merge conflict: Test assessment ✅Both new tests are real logic tests, not tautological:
Tests exercise config/scheme handling (the scope of this PR), not paho's WebSocket transport — appropriate for a "document + test" PR. Verification
MINOR (1)After rebase, the NIT (1)Consider adding the Asks
Verdict: merge after rebase 🟡 |
Summary
CoreScope's ingestor already supports WebSocket MQTT connections today —
paho.mqtt.golangv1.5.0 handlesws://andwss://natively via gorilla/websocket. However this support was undocumented, untested, and had a TLS gap forwss://connections.This PR closes those gaps without any breaking changes.
Changes
cmd/ingestor/config.goResolvedSources()explaining all four supported schemes and which ones require translation vs. pass-throughws://andwss://explicitly documented as native paho schemes requiring no mappingcmd/ingestor/main.gowss://in addition tossl://wss://connections would use paho's default TLS (no explicittls.Configset), which works for valid certs but doesn't apply the same predictable setup asssl://ssl://andwss://gettls.Config{}(system CA pool), matching behavior;rejectUnauthorized: falsestill works for self-signed certs on both schemescmd/ingestor/config_test.goTwo new tests:
TestResolvedSourcesSchemeMapping: validates all six scheme variations (mqtt://,mqtts://,tcp://,ssl://,ws://,wss://) including paths likewss://host/mqttTestLoadConfigWSSource: full round-trip of a dual-source config (TCP + wss:// with username/password), verifies scheme unchanged throughLoadConfigandResolvedSourcesconfig.example.jsonwsmqttexample entry showingwss://with username/password_comment_mqttSourcesto enumerate all supported schemes:mqtt://,mqtts://,ws://,wss://Motivation
We run meshcore-mqtt-broker (a WebSocket MQTT bridge with JWT auth) alongside Mosquitto, and subscribe to both via
mqttSources. The dual-source config works in production but nothing in the docs or example config made this discoverable for other operators.Testing
All existing tests pass. Two new tests added.
No breaking changes
ws:///wss://configs that were already working: same behavior + explicit TLS setup forwss://