镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

SocketsHttpHandler should throw instead of returning proxy response message when proxy tunnel creation fails #48679

Closed

Description

@geoffkizer

Description

For secure HTTP connections, we attempt to create a proxy tunnel using the CONNECT method against the proxy endpoint. This allows us to create an end-to-end secure SSL connection between client and destination server.

If the proxy CONNECT request fails, (i.e. returns a status other than 200), we return the proxy's response to the user. However, this means the user can't distinguish whether the response came from the proxy or the destination server. This is problematic because the user is using SSL and thus reasonably expects that any response has been securely delivered via the end-to-end secure connection.

I think we should change this behavior, and instead throw an HttpRequestException when a proxy tunnel CONNECT request fails. Something like "The proxy tunnel request to proxy {proxyUri} failed with status code {statusCode}."

Note that for non-secure requests, we always return the proxy response and the user can't tell whether the response came from the destination server unmodified, or was modified by the proxy, or was simply generated by the proxy without even contacting the destination server. This is intentional; for non-secure requests, proxies are explicitly allowed to do whatever they want to a request, including modifying it, blocking it entirely, etc.

Activity

  1. added this to the 6.0.0 milestone on Feb 24, 2021
  2. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Feb 24, 2021
  3. changed the title [-]SocketsHttpHandler should not return proxy response message when proxy tunnel creation fails[/-] [+]SocketsHttpHandler should throw instead of returning proxy response message when proxy tunnel creation fails[/+] on Feb 24, 2021
  4. wfurt commented on Feb 24, 2021

    @wfurt
    Member

    make sense to me. basically treat CONNECT failures as form of connect() failure. How about authentication failures? They should have distinct status code, right?

  5. geoffkizer commented on Feb 24, 2021

    @geoffkizer
    ContributorAuthor

    Yeah, an auth failure will show up as a 407 status code.

  6. removed
    untriagedNew issue has not been triaged by the area owner
    on Mar 4, 2021
  7. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Apr 6, 2021
  8. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Apr 6, 2021
  9. ghost locked as resolved and limited conversation to collaborators on May 6, 2021
  10. added
    needs-breaking-change-doc-createdBreaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet
    on Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-System.Net.Httpneeds-breaking-change-doc-createdBreaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions