Настройка gRPC-канала Pub/Sub Java для HTTP CONNECT

Используйте поставщик канала сгенерированного клиента, когда соединению Pub/Sub Java gRPC нужен прокси HTTP CONNECT. Обычная настройка URLConnection не создаёт такую конфигурацию канала.

Для клиента topic-admin:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient и TopicAdminSettings — классы Pub/Sub v1; HttpConnectProxiedSocketAddress происходит из io.grpc, а InetSocketAddress — из java.net. В примере предполагается обычная цель в виде интернет-адреса, которую использует этот канал.

Детектор возвращает адрес прокси-соединения вместе с исходной целью. Построитель gRPC требует, чтобы адрес прокси был разрешён. Оставьте конечную точку службы как Pub/Sub: замена её именем хоста прокси привела бы к потере цели службы и предполагаемой TLS-идентичности.

Удалите вызовы имени пользователя и пароля для прокси без аутентификации; публичные кандидаты HTTP есть в списке HTTP-прокси. Эти вызовы — интерфейс учётных данных HTTP CONNECT, а не SOCKS или общая реализация NTLM.

Если сбой происходит до операции gRPC, пока независимо созданные учётные данные получают токен, проверьте HTTP-маршрут этих учётных данных. Он находится вне показанного здесь поставщика канала.