What happens
A plugin mounted at a dotted prefix (e.g. /.terminal) cannot accept WebSocket connections — the upgrade fails immediately — while the same plugin at /terminal works. Plain HTTP on a dotted prefix (e.g. /.notifications) happens to work, so the failure is upgrade-specific and surprising.
Core reserves specific dotted paths (/.terminal, /.webrtc) for its own built-ins in the WAC-skip/upgrade handling, and a plugin claiming a dotted prefix collides with that host-level dotfile handling in a way plain prefixes don't.
Evidence
Found while porting the bundled terminal feature out-of-tree: https://github.com/JavaScriptSolidServer/plugins (NOTES.md, "Bugs the composition surfaced"). The composition there uses /terminal as the workaround.
Suggested fix
Either validate at load time (refuse or warn on a dotted prefix for plugins that register WS routes), or document the reservation so plugin authors don't discover it via a dead socket.
What happens
A plugin mounted at a dotted prefix (e.g.
/.terminal) cannot accept WebSocket connections — the upgrade fails immediately — while the same plugin at/terminalworks. Plain HTTP on a dotted prefix (e.g./.notifications) happens to work, so the failure is upgrade-specific and surprising.Core reserves specific dotted paths (
/.terminal,/.webrtc) for its own built-ins in the WAC-skip/upgrade handling, and a plugin claiming a dotted prefix collides with that host-level dotfile handling in a way plain prefixes don't.Evidence
Found while porting the bundled terminal feature out-of-tree: https://github.com/JavaScriptSolidServer/plugins (NOTES.md, "Bugs the composition surfaced"). The composition there uses
/terminalas the workaround.Suggested fix
Either validate at load time (refuse or warn on a dotted
prefixfor plugins that register WS routes), or document the reservation so plugin authors don't discover it via a dead socket.