Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[BUG] Align OkHttp and Netty handling of HTTP 407 responses after HTTPS tunnel establishment

Chiusa
  • Qualcosa non va?
#50,799 2 commenti 1 reazione 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@alzimmermsft ci sta già lavorando.

Dal 14/10/2026.

  • #50828 di @alzimmermsft — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Azure.Core Client

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:

  1. Configure an HTTP proxy and an HTTPS test endpoint.
  2. Allow proxy CONNECT negotiation and TLS establishment to complete normally.
  3. Have the HTTPS test endpoint return HTTP 407 (Proxy Authentication Required) over the established TLS connection.
  4. Send the same request using azure-core-http-okhttp and azure-core-http-netty with equivalent proxy settings.
  5. 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 at 1.14.0-beta.1, with OkHttp 4.12.0) and com.azure:azure-core-http-netty for 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
Lingua principale
Java
Stelle
2.6k
Fork
2.2k
Merge medio
1g 18h
PR unite (30g)
231

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Azure/azure-sdk-for-java

Tutte le issue di Azure/azure-sdk-for-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.