Configurer le canal gRPC de Pub/Sub Java pour HTTP CONNECT
Installez un ProxyDetector via le fournisseur de canal GAX, en conservant l'adresse cible et l'identité TLS de Pub/Sub.
Utilisez le fournisseur de canal du client généré lorsqu'une connexion Pub/Sub Java gRPC nécessite un proxy HTTP CONNECT. Un réglage URLConnection ordinaire n'établit pas cette configuration de canal.
Pour le client 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 et TopicAdminSettings sont des classes Pub/Sub v1 ; HttpConnectProxiedSocketAddress vient de io.grpc et InetSocketAddress de java.net. L'exemple suppose la cible d'adresse Internet habituelle utilisée par ce canal.
Le détecteur renvoie une adresse de connexion proxy à côté de la cible d'origine. Le constructeur gRPC exige que l'adresse du proxy soit résolue. Laissez le point de terminaison du service sur Pub/Sub : le remplacer par le nom d'hôte du proxy ferait perdre la cible du service et l'identité TLS prévue.
Supprimez les appels de nom d'utilisateur/mot de passe pour un proxy non authentifié ; des candidats HTTP publics figurent dans la liste de proxys HTTP. Ces appels constituent l'interface d'identification HTTP CONNECT, non SOCKS ni une implémentation NTLM générale.
Si l'échec survient avant l'opération gRPC alors qu'un identifiant créé indépendamment obtient un jeton, inspectez la route HTTP de cet identifiant. Elle se situe hors du fournisseur de canal présenté ici.