Repository navigation
[BUG] Align OkHttp and Netty handling of HTTP 407 responses after HTTPS tunnel establishment #50799
Description
Describe the bug
The OkHttp and Netty HTTP transports handle an HTTP 407 response differently when it is returned by an HTTPS endpoint after an HTTP proxy CONNECT tunnel has already been established.
The response is an endpoint response received over the established TLS connection, not a response to the proxy CONNECT request. However, the OkHttp path can invoke proxy-specific handling and issue a follow-up request, while the Netty path treats it as an endpoint response without restarting proxy negotiation.
This issue tracks consistent HTTP response handling when applications switch between transports.
Exception or Stack Trace
Not applicable. This is a response-handling and retry-behavior difference rather than an exception report.
To Reproduce
Use a controlled local test environment:
- Configure an HTTP proxy and an HTTPS test endpoint.
- Allow proxy CONNECT negotiation and TLS establishment to complete normally.
- Have the HTTPS test endpoint return HTTP 407 (
Proxy Authentication Required) over the established TLS connection. - Send the same request using
azure-core-http-okhttpandazure-core-http-nettywith equivalent proxy settings. - Compare the transport-level response handling and whether a proxy-related follow-up is attempted.
The behavior below is based on implementation review; these steps have not been run locally for this tracking issue.
| Transport | Behavior for the endpoint-generated 407 after tunnel establishment |
|---|---|
| OkHttp | OkHttp can invoke the configured proxy authenticator for this response. The SDK authenticator does not distinguish it from a CONNECT-phase response and can produce a proxy-related follow-up request. |
| Netty | Proxy negotiation is handled during CONNECT. Once the tunnel is established, an endpoint-generated 407 does not re-enter the proxy authentication path; it remains an endpoint response for the SDK pipeline/caller to handle. |
Code Snippet
No application snippet is included. The HTTPS test fixture should return status 407 after successful CONNECT and TLS establishment. Use existing proxy test fixtures and compare transport-level behavior independently of service-specific retry policies.
Expected behavior
An endpoint-generated HTTP 407 received inside an established HTTPS tunnel should not restart proxy negotiation. OkHttp and Netty should behave consistently for this scenario.
Acceptance criteria:
- Align OkHttp post-tunnel 407 handling with Netty's connection-phase behavior.
- Preserve normal handling of genuine proxy 407 responses during CONNECT.
- Preserve supported cleartext HTTP proxy behavior.
- Add regression tests for post-tunnel 407 responses, including reuse of an established connection.
- Cover HTTP/1.1 and HTTP/2 endpoint connections where supported.
Screenshots
Not applicable.
Setup (please complete the following information):
- OS: Not OS-specific; implementation review.
- IDE: Not applicable.
- Library/Libraries:
com.azure:azure-core-http-okhttp(reviewed at1.14.0-beta.1, with OkHttp4.12.0) andcom.azure:azure-core-http-nettyfor behavior comparison. - Java version: No local runtime reproduction performed for this tracking issue.
- App Server/Environment: Java application using an Azure SDK HTTP transport through an HTTP proxy to a controlled HTTPS endpoint.
- Frameworks: None required.
A dependency version mismatch is not suspected. Dependency-tree output and exception logs are not applicable to this tracking issue.
Additional context
Review the OkHttp ProxyAuthenticator and its builder integration against the Netty proxy handling lifecycle. The goal is transport parity and predictable response handling, not a public API change. Keep the change focused on distinguishing CONNECT-phase responses from endpoint responses and adding related regression coverage.
Information Checklist
- Bug Description Added
- Repro Steps Added (controlled test scenario provided; not executed locally)
- Setup information Added
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
github-actions commentedon Oct 14, 2026
Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.
github-actions commentedon Oct 14, 2026
🎯 Agentic Issue Triage
Summary: The OkHttp and Netty HTTP transports in azure-core handle an endpoint-generated HTTP 407 (returned after an HTTPS CONNECT tunnel is already established) inconsistently — OkHttp can re-invoke proxy authentication handling for it, while Netty treats it purely as an endpoint response.
📋 Issue Details
Package:
com.azure:azure-core-http-okhttp(reviewed at1.14.0-beta.1, OkHttp4.12.0), compared againstcom.azure:azure-core-http-nettyAffected API: OkHttp
ProxyAuthenticatorand its builder integration vs. Netty's proxy/CONNECT handling lifecycleScenarios:
Root ask: Align OkHttp's post-tunnel 407 handling with Netty's, so an endpoint-generated 407 inside an established tunnel does not restart proxy negotiation, while preserving correct behavior for genuine CONNECT-phase 407s and cleartext HTTP proxy scenarios. Regression tests covering HTTP/1.1 and HTTP/2 are requested.
🔎 Debugging / Reproduction Notes
This is a tracking/design issue based on implementation review rather than an executed repro; no stack trace or exception is involved — it's a behavioral-parity concern between two
azure-coreHTTP transport implementations.Suggested investigation steps:
ProxyAuthenticatorinazure-core-http-okhttpto determine how it distinguishes CONNECT-phase 407 responses from endpoint-returned 407 responses over an already-tunneled connection.azure-core-http-nettyto confirm it never re-enters proxy auth once the tunnel is established.Note: Automated reference-issue search via
gh searchwas unavailable in this environment (tool returned an error), so no duplicate/similar-issue check could be performed.🏷️ Label Confidence
Client— The issue is about SDK transport implementation behavior (azure-core-http-okhttp/azure-core-http-netty), not REST API/service behavior or engineering systems.Azure.Core— Both affected packages live undersdk/core/, which maps to theAzure.Coreservice label per CODEOWNERS.sdk/core/package routing.👥 Owner Routing
# ServiceLabel: %Azure.Core(sdk/core/ section) — matched because the predicted service label isAzure.Coreand this entry lists an AzureSdkOwner.@alzimmermsft@alzimmermsftas the sole AzureSdkOwner for this entry.%ARM - Core,%clientcore,%Azure.Core.V2, and%Azure.Core.AMQPwere checked but required different/additional labels not present on this issue (e.g., Mgmt, AMQP-specific), so the general%Azure.Coreentry under/sdk/core/was the correct match.