خطای پروکسی HttpClient 4: پروتکل http پشتیبانی نمی‌شود

در برنامه‌ای با Apache HttpClient 4، مقصد HTTPS به معنای آن نیست که هر اتصال با TLS آغاز می‌شود. به یک پروکسی HTTP معمولی از طریق اتصالی بدون رمزنگاری می‌رسیم، پیش از آنکه CONNECT تونل را باز کند و TLS به سمت مقصد لایه‌بندی شود.

اگر مدیر اتصال سفارشی فقط https را ثبت کند، نخستین جهش پروکسی ممکن است با UnsupportedSchemeException: http protocol is not supported شکست بخورد.

برای API نسخه 4.5، هنگام ساخت آن مدیر هر دو کارخانه را بگنجانید:

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 همان SSLConnectionSocketFactory موجود برنامه است با بررسی موردنظر اعتماد و نام میزبان. نوع‌های نشان‌داده‌شده به بسته‌های org.apache.http در Apache 4 تعلق دارند. این قطعه استنتاج نوع متغیرهای محلی Java را فرض می‌کند؛ کد Java قدیمی‌تر می‌تواند از نوع‌های صریح استفاده کند.

مدیر اصلاح‌شده را به کلاینتی متصل کنید که واقعاً برای درخواست استفاده می‌شود. برای یک درخواست HTTPS عمومی مجاز بدون احراز هویت پروکسی، یک ورودی HTTP از فهرست پروکسی‌های HTTP می‌تواند نشانی پروکسی HttpHost را پر کند. پیکربندی سازنده‌ای دیگر کلاینت ساخته‌شده را به‌روز نمی‌کند.

مالکیت سازنده را نیز بررسی کنید: HttpClientBuilder مستند می‌کند که مدیر اتصال صریحاً ارائه‌شده می‌تواند ورودی‌های جداگانه پیکربندی SSL آن را زیر پا بگذارد. کارخانه‌های لازم را در ثبت مدیر قرار دهید، نه اینکه فرض کنید فراخوانی بعدی setSSLContext درون آن را جایگزین می‌کند.

این تشخیص به ثبت محلی طرح‌ها مربوط است. چالش احراز هویت پروکسی یا مقصد ردشده نتیجه‌ای بعدی و متفاوت است. هنگام بررسی آن پاسخ‌ها هر دو ثبت کارخانه را حفظ کنید.