Konfigurer Pub/Sub Javas gRPC-kanal for HTTP CONNECT
Installer en ProxyDetector via GAX-kanalleverandøren, og behold Pub/Subs måladresse og TLS-identitet.
Bruk den genererte klientens kanalleverandør når en Pub/Sub Java gRPC-tilkobling trenger en HTTP CONNECT-proxy. En vanlig URLConnection-innstilling etablerer ikke denne kanalkonfigurasjonen.
For topic-admin-klienten:
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 og TopicAdminSettings er Pub/Sub v1-klasser; HttpConnectProxiedSocketAddress kommer fra io.grpc og InetSocketAddress fra java.net. Eksempelet forutsetter det vanlige internettadressemålet som denne kanalen bruker.
Detektoren returnerer en proxyforbindelsesadresse sammen med det opprinnelige målet. gRPC-byggeren krever at proxyadressen løses opp. La tjenestens endepunkt være Pub/Sub: å erstatte det med proxyens vertsnavn ville miste tjenestemålet og den tiltenkte TLS-identiteten.
Fjern brukernavn-/passordkallene for en uautentisert proxy; offentlige HTTP-kandidater finnes i listen over HTTP-proxyer. Disse kallene er HTTP CONNECT-legitimasjonsgrensesnittet, ikke SOCKS eller en generell NTLM-implementasjon.
Hvis feilen oppstår før gRPC-operasjonen mens en uavhengig opprettet legitimasjon får et token, undersøk HTTP-ruten til den legitimasjonen. Den ligger utenfor kanalleverandøren som vises her.