Vérifiez si le générateur Tables reçoit un pipeline HTTP complet. Cette entrée remplace son option httpClient distincte ; si l'application possède un pipeline, configurez le transport compatible proxy lors de la construction de ce pipeline.

Pour l'entrée directe du client HTTP Netty, créez le transport et transmettez-le à Tables :

ProxyOptions proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080)
);
proxy.setCredentials(proxyUser, proxyPassword);

HttpClient transport = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

TableClient tables = new TableClientBuilder()
    .connectionString(storageConnectionString)
    .tableName("records")
    .httpClient(transport)
    .buildClient();

HttpClient ici est com.azure.core.http.HttpClient. Les autres types proviennent d'Azure Core HTTP/Netty, d'Azure Data Tables et de java.net.InetSocketAddress. L'application fournit les variables de configuration et d'identification.

ProxyOptions.Type.HTTP sélectionne l'intermédiaire ; setCredentials fournit son compte et peut être omis pour les points de terminaison sans authentification. Dans cette configuration, une entrée d'une liste de proxys HTTP peut fournir l'adresse d'une route autorisée vers un point de terminaison Tables public ; ne laissez aucun identifiant de proxy sur le transport. La chaîne de connexion de stockage choisit toujours le service Tables.

Cela utilise l'authentification par chaîne de connexion. Une configuration avec identifiants d'identité peut disposer d'un client HTTP distinct pour l'acquisition de jetons, dont la route doit également être configurée.

Articles similaires