Bir Apache HttpClient 4 uygulamasında HTTPS hedefi, her bağlantının TLS ile başladığı anlamına gelmez. Sıradan bir HTTP proxy'ye şifrelenmemiş bir bağlantıyla ulaşılır; ardından CONNECT tüneli açar ve TLS hedefe doğru katmanlanır.

Özel bir bağlantı yöneticisi yalnızca https kaydederse, ilk proxy sıçraması UnsupportedSchemeException: http protocol is not supported ile başarısız olabilir.

4.5 API'si için o yöneticiyi oluştururken iki fabrikayı da ekleyin:

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, uygulamanın mevcut SSLConnectionSocketFactory'sidir ve amaçlanan güven ile ana bilgisayar adı doğrulamasını taşır. Gösterilen türler Apache 4'ün org.apache.http paketlerine aittir. Bu parça Java'nın yerel değişken tür çıkarımını varsayar; daha eski Java kodu açık türler kullanabilir.

Düzeltilmiş yöneticiyi istek için gerçekten kullanılan istemciye bağlayın. Proxy kimlik doğrulaması olmadan izin verilen genel bir HTTPS isteği için HTTP proxy listesinden bir HTTP girdisi HttpHost'un proxy adresini doldurabilir. Başka bir builder yapılandırmak, önceden oluşturulmuş bir istemciyi güncellemez.

Builder sahipliğini de inceleyin: HttpClientBuilder, açıkça sağlanan bir bağlantı yöneticisinin ayrı SSL yapılandırma girdilerini geçersiz kılabileceğini belgeler. Gerekli fabrikaları yöneticinin kayıt defterine koyun; daha sonraki bir setSSLContext çağrısının içini değiştireceğini varsaymayın.

Bu tanı yerel şema kayıt defteriyle ilgilidir. Bir proxy kimlik doğrulama meydan okuması veya reddedilen hedef daha sonraki, farklı bir sonuçtur. Bu yanıtları incelerken her iki fabrika kaydını da koruyun.

İlgili makaleler