Konfigurer Pub/Sub Javas gRPC-kanal til HTTP CONNECT

Brug den genererede klients kanaludbyder, når en Pub/Sub Java gRPC-forbindelse har brug for en HTTP CONNECT-proxy. En almindelig URLConnection-indstilling etablerer ikke denne kanalkonfiguration.

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. Eksemplet forudsætter det normale internetadressemål, som denne kanal bruger.

Detektoren returnerer en proxyforbindelsesadresse sammen med det oprindelige mål. gRPC-byggeren kræver, at proxyadressen opløses. Lad tjenestens slutpunkt være Pub/Sub: erstattes det med proxyens værtsnavn, mistes tjenestemålet og den tilsigtede TLS-identitet.

Fjern brugernavn-/adgangskodekaldene for en uautentificeret proxy; offentlige HTTP-kandidater findes i listen over HTTP-proxyer. Disse kald er HTTP CONNECT-legitimationsgrænsefladen, ikke SOCKS eller en generel NTLM-implementering.

Hvis fejlen opstår før gRPC-handlingen, mens en selvstændigt oprettet legitimationsoplysning får et token, skal du undersøge den legitimations HTTP-rute. Den ligger uden for den kanaludbyder, der vises her.