Bufring av ei Jersey 2-opplasting for nye forsøk med proxy-autentisering

Ei opplasting som blir prøvd på nytt etter ei proxy-utfordring, treng kroppen sin igjen. For Apache-koplinga i Jersey 2 vel du bufra eininghandsaming i konfigurasjonen som blir brukt til å byggja den klienten:

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

Utfør opplastinga gjennom klienten som kjem ut. Desse typane kjem frå pakkane Jersey client og Apache-connector; ein ubrukt konfigurasjon ville ikkje påverka førespurnaden.

Koplinga pakkar ei bufra eining inn i BufferedHttpEntity frå Apache. Den ikkje-bufra straumeeininga hennar kan ikkje gjentakast. Bufring gjev autentiseringsflyten byte han kan senda på nytt i staden for å lesa ein brukt produsent om att.

Det garanterer ikkje at autentiseringa sluttar etter éin 407. Nokre skjema krev med rette fleire utvekslingar, så gransk heile forhandlinga før du behandlar ei ny utfordring som tapt tilstand.

Hald kroppsstorleiken innanfor minnebudsjettet. Ei stor straumeopplasting treng ein gjentakingsstrategi som passar for den belastninga; å slå på bufring for kvar førespurnad kan byta ein forhandlingsfeil mot minneutmatting.