SASVA Chat Response Drops Mid-Stream Behind Corporate Proxy/Firewall (SSL Interception)
Problem
On a corporate network with a proxy or firewall in place, SASVA chat responses begin streaming normally — text appears and code starts generating — but the stream stops partway through with no error message, leaving an incomplete response. This is different from a connection being blocked outright at startup: the initial connection succeeds and streaming begins, then cuts off mid-response.
Symptoms
- Chat response starts streaming text/code normally, then abruptly stops mid-sentence or mid-file with no error banner.
- The chat UI does not show "Reconnecting," a timeout message, or any indication that the stream was interrupted — it simply stops.
- The issue is intermittent and correlates with longer-running responses (large files, multi-step tool calls) rather than short replies.
- The same prompt, run from a network without a corporate proxy (e.g., home network, mobile hotspot), completes successfully.
Root Cause
SASVA streams responses using a long-lived HTTP connection. Many corporate proxies and firewalls enforce an idle or maximum-duration timeout on individual connections, and some proxies buffer or inspect streamed content (SSL/TLS interception) in a way that is not fully compatible with long-running streaming responses. When a response takes longer than the proxy's allowed connection duration, or the proxy's buffering logic mishandles the stream, the proxy silently terminates the connection without forwarding an error back to the client — so SASVA has no way to detect or report the interruption, and the partial content already received is all that remains.
This differs from the URL-allowlisting issue in "SASVA Connection Issues on Client Machines", which blocks the connection before it starts. This article covers streams that start successfully and are cut mid-flight by proxy-level timeouts or SSL interception.
Resolution/Workaround
Immediate workaround
- When a response cuts off mid-stream, ask SASVA to "continue from where you left off" in the same chat session.
- For consistently large responses, break the request into smaller prompts (see "SASVA Code Generation Truncated Mid-Response on Large Files" for the same "continue" technique) so each individual stream stays under the proxy's timeout window.
Network-level fixes (requires IT/network team)
- Request that your network/security team add an exception for SASVA's endpoint(s) to bypass SSL interception (deep packet inspection) for that traffic, since interception is a common cause of streaming corruption.
- Ask IT to increase or exempt the idle/connection-duration timeout for the SASVA domain on the corporate proxy, if technically feasible.
- If using a split-tunnel VPN, route SASVA traffic outside the tunnel where corporate proxy policies do not apply, if permitted by policy.
Escalation
If mid-stream drops persist after proxy exceptions are applied, contact sasva_support_in@persistent.com with your organization's proxy/firewall vendor, approximate timeout duration if known, and the point in the response where streaming consistently stops (e.g., "always around 30 seconds" or "always around 500 lines").
Comments