'n Oplaai wat ná 'n proxy-uitdaging herprobeer word, het sy liggaam weer nodig. Vir Jersey 2 se Apache-connector kies gebufferde entiteitsverwerking op die konfigurasie wat vir daardie kliënt gebruik word:

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

Voer die oplaai deur die resulterende kliënt uit. Hierdie tipes kom uit die Jersey-kliënt- en Apache-connector-pakkette; 'n ongebruikte konfigurasie sou die versoek nie beïnvloed nie.

Die connector verpak 'n gebufferde entiteit in Apache se BufferedHttpEntity. Sy nie-gebufferde stromingsentiteit is nie herhaalbaar nie. Buffering gee die verifikasievloei grepe wat dit weer kan stuur eerder as om 'n verbruikte produsent weer te lees.

Dit waarborg nie dat verifikasie ná een 407 eindig nie. Sommige skemas vereis wettiglik verskeie uitruilings, so ondersoek die hele onderhandeling voordat jy 'n verdere uitdaging as verlore toestand beskou.

Hou die liggaamsgrootte binne die geheuebegroting. 'n Groot stroming-oplaai benodig 'n herhaalstrategie wat by daardie werklading pas; om buffering vir elke versoek te aktiveer, kan 'n onderhandelingsfout vir geheue-uitputting verruil.

Verwante artikels