Proksi chaqirig'idan keyin qayta urinilgan yuklama o'z tanasini yana talab qiladi. Jersey 2 ning Apache connector uchun o'sha klient quriladigan konfiguratsiyada buferlangan obyektni qayta ishlashni tanlang:

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ClientProperties.PROXY_URI,
                "http://proxy.example.net:8080");
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
                RequestEntityProcessing.BUFFERED);

Yuklamani hosil bo'lgan klient orqali bajaring. Bu turlar Jersey client va Apache-connector paketlaridan keladi; ishlatilmaydigan konfiguratsiyani o'rnatish so'rovga ta'sir qilmaydi.

Connector buferlangan obyektni Apache ning BufferedHttpEntity ichiga o'raydi. Uning buferlanmagan oqim obyekti takrorlanmaydi. Buferlash autentifikatsiya oqimiga sarflangan ishlab chiqaruvchini qayta o'qish o'rniga qayta yuborish mumkin bo'lgan baytlar beradi.

Bu autentifikatsiya bitta 407 dan keyin tugashiga kafolat bermaydi. Ayrim sxemalar qonuniy ravishda bir nechta almashinuvni talab qiladi, shuning uchun keyingi chaqiriqni yo'qolgan holat deb hisoblashdan oldin butun muzokarani ko'rib chiqing.

Tana hajmini xotira byudjeti ichida saqlang. Katta oqimli yuklama shu yuklamaga mos qayta ijro strategiyasini talab qiladi; har bir so'rov uchun buferlashni yoqish muzokara muvaffaqiyatsizligini xotira tugashi bilan almashtirishi mumkin.

O'xshash maqolalar