Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve exceptions thrown when an error happens during proxy CONNECT #2721

Merged
merged 2 commits into from
Oct 4, 2023

Conversation

idelpivnitskiy
Copy link
Member

@idelpivnitskiy idelpivnitskiy commented Oct 2, 2023

Motivation:

ProxyResponseException is marked as RetryableException. However, not all response statuses are retryable. For example, it doesn't make sense to auto-retry if proxy responds with 4xx (proxy auth required, bad request, etc.).
Also, because proxy-related exceptions live in servicetalk-http-netty, gprc-api can not access them for better mapping into gRPC status code.

Modifications:

  • Move ProxyConnectException from http-netty to http-api;
  • Deprecate ProxyResponseException, introduce ProxyConnectResponseException instead in http-api;
  • Use a retryable variant of ProxyConnectResponseException only for specific status codes from a proxy server are are intended to be retryable;
  • Include Channel info in every thrown ProxyConnectException;
  • Enhance GrpcStatusException to recognize ProxyConnectResponseException;
  • Extract HttpResponseStatus -> GrpcStatusCode mapping into GrpcUtils.fromHttpStatus(...) utility, add support for PROXY_AUTHENTICATION_REQUIRED status;
  • Enhance tests to verify expected behavior;

Results:

  1. ProxyResponseException and ProxyConnectResponseException are part of http-api now.
  2. http-netty is careful when proxy related exceptions should be marked as RetryableException and when not.
  3. grpc-api recognizes ProxyConnectResponseException and infers better grpc-status instead of always using UNKNOWN.

@idelpivnitskiy idelpivnitskiy requested a review from daschl October 2, 2023 22:06
@idelpivnitskiy idelpivnitskiy self-assigned this Oct 2, 2023
package io.servicetalk.http.netty;

import io.servicetalk.transport.api.RetryableException;
package io.servicetalk.http.api;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class was not released yet (introduced in #2711). Safe to move without going through deprecation process

Motivation:

`ProxyResponseException` is marked as `RetryableException`. However, not
all response statuses are retryable. For example, it doesn't make sense
to auto-retry if proxy responds with 4xx (proxy auth required, bad
request, etc.).
Also, because proxy-related exceptions live in `servicetalk-http-netty`,
gprc-api can not access them for better mapping into gRPC status code.

Modifications:

- Move `ProxyConnectException` from `http-netty` to `http-api`;
- Deprecate `ProxyResponseException`, introduce
`ProxyConnectResponseException` instead in `http-api`;
- Use a retryable variant of `ProxyConnectResponseException` only for
5xx responses from a proxy server;
- Include Channel info in every thrown `ProxyConnectException`;
- Enhance `GrpcStatusException` to recognize
`ProxyConnectResponseException`;
- Extract `HttpResponseStatus` -> `GrpcStatusCode` mapping into
`GrpcUtils.fromHttpStatus(...)` utility, add support for
`PROXY_AUTHENTICATION_REQUIRED` status;
- Enhance tests to verify expected behavior;

Results:

1. `ProxyResponseException` and `ProxyConnectResponseException` are
part of `http-api` now.
2. `http-netty` is careful when proxy related exceptions should be
marked as `RetryableException` and when not.
3. grpc-api recognizes `ProxyConnectResponseException` and infers better
grpc-status instead of always using `UNKNOWN`.
@idelpivnitskiy idelpivnitskiy merged commit 1a65e86 into apple:main Oct 4, 2023
15 checks passed
@idelpivnitskiy idelpivnitskiy deleted the proxyExceptions branch October 4, 2023 17:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants