Closed
Description
Hi folks,
We rely heavily on AHC for its performance and async support in many internal projects. However, we've recently encountered multiple escalations regarding unusual HTTP 400 errors.
Context
Our applications operate under strict network restrictions and must use an HTTP proxy to access external servers. This setup has worked reliably for years.
Issue Details
We've identified that when initializing an HTTPS tunnel via a proxy:
- If the initial CONNECT request fails (e.g., 503/403), the connection is pooled rather than abandoned.
- All subsequent requests on this connection fail with HTTP 400 (INVALID_URL) because only the HTTP path is sent instead of a fully qualified URL (as required by the proxy).
- Although the scheme is HTTPS, the payload is sent in cleartext after the failure.
- Once this issue starts, it persists indefinitely.
- Furthermore, as the proxy responds HTTP400 after receiving the client request immediately, the "bad" connections have higher chance of being selected for the requests.
Expected Behavior
- The client should either abandon the connection or retry the CONNECT request to recover.
- Failed connections should not be reused in a way that leads to invalid HTTP requests.
Actual Behavior
- The client neither abandons nor reattempts the CONNECT request.
- Instead, it continues sending requests in cleartext, leading to persistent failures.
This appears to be a bug in the error handling logic.
Thanks
Jason
Metadata
Metadata
Assignees
Labels
No labels