Agordi la gRPC-kanalon de Pub/Sub Java por HTTP CONNECT

Uzu la kanalan provizanton de la generita kliento kiam Pub/Sub Java gRPC-konekto bezonas HTTP CONNECT-prokuron. Ordinara URLConnection-agordo ne starigas ĉi tiun kanalan agordon.

Por la topic-admin-kliento:

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 kaj TopicAdminSettings estas Pub/Sub v1-klasoj; HttpConnectProxiedSocketAddress venas de io.grpc kaj InetSocketAddress de java.net. La ekzemplo supozas la kutiman interretan celadreson uzatan de ĉi tiu kanalo.

La detektilo redonas prokurkan konektadreson apud la origina celo. La gRPC-konstruilo postulas, ke la prokura adreso estu solvita. Lasu la servan finpunkton kiel Pub/Sub: anstataŭigi ĝin per la prokura gastiga nomo perdus la servan celon kaj la intencitan TLS-identecon.

Forigu la uzantnomon/pasvorton-vokojn por neaŭtentigita prokuro; publikaj HTTP-kandidatoj troveblas en la listo de HTTP-prokuriloj. Tiuj vokoj estas la HTTP CONNECT-akreditila interfaco, ne SOCKS aŭ ĝenerala NTLM-implementaĵo.

Se la malsukceso okazas antaŭ la gRPC-operacio dum sendepende kreita akreditaĵo akiras ĵetonon, kontrolu la HTTP-vojon de tiu akreditaĵo. Ĝi estas ekster la ĉi tie montrita kanala provizanto.