Kontroller om Tables-byggeren mottar en fullstendig HTTP-pipeline. Denne inndataen overstyrer dens separate httpClient-alternativ; hvis applikasjonen eier en pipeline, konfigurer den proxybevisste transporten når du bygger den pipelinen.

For den direkte Netty HTTP-klientinndataen bygger du transporten og sender den til 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 her er com.azure.core.http.HttpClient. De andre typene kommer fra Azure Core HTTP/Netty, Azure Data Tables og java.net.InetSocketAddress. Applikasjonen leverer konfigurasjons- og legitimasjonsvariablene.

ProxyOptions.Type.HTTP velger mellomleddet; setCredentials leverer kontoen og kan utelates for endepunkter uten autentisering. I den konfigurasjonen kan en oppføring fra en HTTP-proxyliste levere adressen for en tillatt offentlig Tables-endepunktrute; ikke la proxy-legitimasjon bli igjen på transporten. Lagringsforbindelsesstrengen velger fortsatt Tables-tjenesten.

Dette bruker forbindelsesstrengautentisering. En identitetslegitimasjonsordning kan ha en egen HTTP-klient for tokeninnhenting, hvis rute også må konfigureres.

Relaterte artikler