Настройване на gRPC канала на Pub/Sub Java за HTTP CONNECT
Инсталирайте ProxyDetector чрез доставчика на канал GAX, като запазите целевия адрес и TLS самоличността на Pub/Sub.
Използвайте доставчика на канал на генерирания клиент, когато връзката 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 маршрута на тези данни. Той е извън показания тук доставчик на канал.