Edge-to-Edge Forwarding

Status: Implemented

Overview

When multiple edge servers are deployed, a public HTTP request may arrive at an edge that does not have the target agent connected. Edge-to-edge forwarding allows the receiving edge to discover which peer owns the agent (via the Bridge database) and transparently forward the request.

Components

Bridge (Laravel)

• Migration: create_edge_sessions_table -- tracks which edge instance owns each subdomain.
• Model: EdgeSession -- edge_id, subdomain, connected_at, last_seen_at.
• API endpoints (authenticated with jetty.edge middleware):
  • POST /api/edge/sessions -- edge reports a connected agent.
  • GET /api/edge/sessions/{subdomain} -- lookup which edge has an agent.
  • DELETE /api/edge/sessions/{subdomain} -- edge reports agent disconnected.

Edge (Go)

• Config: JETTY_EDGE_ID, JETTY_EDGE_PEERS (comma-separated peer URLs), JETTY_EDGE_FORWARD_SECRET.
• On agent register: POST to Bridge /api/edge/sessions.
• On agent unregister: DELETE from Bridge.
• handlePublicHTTP: if subdomain not in local sessions and request is not already forwarded, query Bridge for agent location. If another edge has it, forward via POST /internal/forward on the peer.
• Cache: Bridge lookups cached for 30 seconds per subdomain.
• Internal endpoint: POST /internal/forward -- receives forwarded requests, authenticated with X-Jetty-Edge-Secret, routes to local agent via WebSocket.
• Loop prevention: X-Jetty-Forwarded-From header; rejected if already present on incoming public request, required on internal forward requests.