HttpClient 4-proxyfejl: http-protokollen understøttes ikke

I en Apache HttpClient 4-applikation betyder en HTTPS-destination ikke, at hver forbindelse starter med TLS. En almindelig HTTP-proxy nås over en ukrypteret forbindelse, før CONNECT åbner tunnelen og TLS lægges oven på mod destinationen.

Hvis en brugerdefineret forbindelsesmanager kun registrerer https, kan det første proxyspring fejle med UnsupportedSchemeException: http protocol is not supported.

Til 4.5-API'en skal begge fabrikker med, når den manager bygges:

var registry = RegistryBuilder.<ConnectionSocketFactory>create()
    .register("http", PlainConnectionSocketFactory.getSocketFactory())
    .register("https", tlsFactory)
    .build();

var manager = new PoolingHttpClientConnectionManager(registry);
var client = HttpClients.custom()
    .setConnectionManager(manager)
    .setProxy(new HttpHost("proxy.example.net", 8080, "http"))
    .build();

tlsFactory er applikationens eksisterende SSLConnectionSocketFactory med den tilsigtede kontrol af tillid og værtsnavn. De viste typer hører til Apache 4's org.apache.http-pakker. Uddraget forudsætter Javas lokale variabeltypeinferens; ældre Java-kildekode kan bruge eksplicitte typer.

Knyt den rettede manager til den klient, der faktisk bruges til anmodningen. Til en tilladt offentlig HTTPS-anmodning uden proxygodkendelse kan en HTTP-post fra HTTP-proxylisten udfylde HttpHosts proxyadresse. At konfigurere en anden builder opdaterer ikke en allerede oprettet klient.

Undersøg også builderens ejerskab: HttpClientBuilder dokumenterer, at en eksplicit leveret forbindelsesmanager kan tilsidesætte dens separate SSL-konfigurationsinput. Læg de nødvendige fabrikker i managerens register i stedet for at antage, at et senere setSSLContext-kald erstatter dens indre.

Denne diagnose handler om det lokale skemaregister. En proxygodkendelsesudfordring eller en afvist destination er et senere, anderledes resultat. Behold begge fabriksregistreringer, mens du undersøger disse svar.