Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#50,799 コメント 2 件 リアクション 1 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@alzimmermsft がすでに取り組んでいます。

2026年10月14日 から。

  • #50828 @alzimmermsft による — オープン

評価

この issue はまだ評価されていません。

説明

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
主要言語
Java
スター
2.6k
フォーク
2.2k
平均マージ
1日 22時間
マージ済み PR（30日）
213

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Azure/azure-sdk-for-java のほかの issue

Azure/azure-sdk-for-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。