* fix: abort in-flight HTTP requests on client disconnect
Abort running agent commands when the HTTP client disconnects for both
/v1/chat/completions and /v1/responses endpoints.
- Listen on res "close" instead of req "close" (the request body is
already consumed so IncomingMessage auto-destroys before we get here).
- Non-streaming: guard with !signal.aborted so the abort fires on
genuine disconnects; a spurious abort after sendJson is harmless.
- Streaming: guard with !closed so normal res.end() completions do not
abort post-turn work still in flight.
- Skip error logging and response writes when the signal is already
aborted.
Made-with: Cursor
* fix: correct event listener name and improve error handling in HTTP requests
Updated the event listener for client disconnects to use the correct name and enhanced error handling logic. The changes ensure that abort signals are properly checked before logging errors and returning responses, preventing unnecessary operations on aborted requests.
Made-with: Cursor
* fix: use correct 'close' event name for non-streaming disconnect handler
* fix: watch socket close for HTTP aborts
---------
Co-authored-by: 冰森 <dingheng.huang@urbanic.com>
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* security: add baseline security headers to gateway HTTP responses
All responses from the gateway HTTP server now include
X-Content-Type-Options: nosniff and Referrer-Policy: no-referrer.
These headers are applied early in handleRequest, before any
handler runs, ensuring coverage for every response including
error pages and 404s.
Headers that restrict framing (X-Frame-Options, CSP
frame-ancestors) are intentionally omitted at this global level
because the canvas host and A2UI handlers serve content that may
be loaded inside frames.
* fix: apply security headers before WebSocket upgrade check
Move setDefaultSecurityHeaders() above the WebSocket early-return so
the headers are set on every HTTP response path including upgrades.
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
* feat(gateway): add auth rate-limiting & brute-force protection
Add a per-IP sliding-window rate limiter to Gateway authentication
endpoints (HTTP, WebSocket upgrade, and WS message-level auth).
When gateway.auth.rateLimit is configured, failed auth attempts are
tracked per client IP. Once the threshold is exceeded within the
sliding window, further attempts are blocked with HTTP 429 + Retry-After
until the lockout period expires. Loopback addresses are exempt by
default so local CLI sessions are never locked out.
The limiter is only created when explicitly configured (undefined
otherwise), keeping the feature fully opt-in and backward-compatible.
* fix(gateway): isolate auth rate-limit scopes and normalize 429 responses
---------
Co-authored-by: buerbaumer <buerbaumer@users.noreply.github.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
