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.

Relaterte artikler