WebSocket upgrades not tunneled on domain-routed (Host-based) requests #59
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_proxy#59
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
dispatch_domain_route(the Host-based routing path that every per-tenant domain uses) forwards requests with the plain HTTP forwarders, which finish the request and response but never wire up the socket after a 101 Switching Protocols, so browser WebSocket connections through a tenant domain reconnect-loop even though normal pages load fine. Theis_ws_upgradeshort-circuit only existed in the path-prefix handler. I fixed this onmainin 1ab1406 by adding the same short-circuit todispatch_domain_routefor http and https targets (reusingforward_ws_to_upstream, which now takes astrip_prefixargument so it matchesforward_to_upstream). Verified live: the assistant chat now streams through the gateway on a tenant domain. Heads up thatdevelopmentstill has the bug and needs the same change or a forward-merge ofmain, and that socket-target domain routes still have no Unix-socket WebSocket tunnel (none use a socket target for WebSocket traffic today). cc @sameh-farouk