Bufrimi i një ngarkimi Jersey 2 për riprovat e autentikimit përmes proxy

Bëni entitetin e kërkesës Jersey 2 me lidhësin Apache të përsëritshëm kur negociimi i autentikimit duhet të dërgojë përsëri ngarkimin.

Një ngarkim i riprovuar pas një sfide të proxy-t ka nevojë përsëri për trupin e tij. Për lidhësin Apache të Jersey 2, zgjidhni përpunimin e entitetit të bufruar në konfigurimin me të cilin ndërtohet ai klient:

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);

Kryeni ngarkimin përmes klientit që rezulton. Këto tipe vijnë nga paketat Jersey client dhe Apache-connector; vendosja e një konfigurimi të papërdorur nuk do të ndikonte në kërkesë.

Lidhësi e mbështjell një entitet të bufruar në BufferedHttpEntity të Apache. Entiteti i tij transmetues i pabufruar nuk është i përsëritshëm. Bufrimi i jep rrjedhës së autentikimit bajt që mund t'i dërgojë përsëri në vend që të rilexojë një prodhues tashmë të konsumuar.

Nuk garanton që autentikimi përfundon pas një 407. Disa skema kërkojnë ligjërisht disa shkëmbime, prandaj shqyrtoni të gjithë negociimin përpara se ta trajtoni një sfidë tjetër si gjendje të humbur.

Mbani madhësinë e trupit brenda buxhetit të memories. Një ngarkim i madh transmetues ka nevojë për një strategji ripërsëritjeje të përshtatshme për atë ngarkesë; aktivizimi i bufrimit për çdo kërkesë mund të shkëmbejë një dështim negociimi me shterimin e memories.

Artikuj të ngjashëm