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

En opplasting som prøves på nytt etter en proxy-utfordring, trenger kroppen sin igjen. For Jersey 2s Apache-kobling velger du bufret entitetsbehandling i konfigurasjonen som brukes til å bygge 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 opplastingen gjennom klienten som oppstår. Disse typene kommer fra pakkene Jersey client og Apache-connector; en ubrukt konfigurasjon ville ikke påvirke forespørselen.

Koblingen pakker en bufret entitet inn i Apaches BufferedHttpEntity. Dens ubufrede strømmeentitet kan ikke gjentas. Bufring gir autentiseringsflyten bytes den kan sende på nytt i stedet for å lese en brukt produsent på nytt.

Det garanterer ikke at autentiseringen slutter etter én 407. Noen skjemaer krever med rette flere utvekslinger, så undersøk hele forhandlingen før du behandler nok en utfordring som tapt tilstand.

Hold kroppsstørrelsen innenfor minnebudsjettet. En stor strømmeopplasting trenger en gjentakelsesstrategi som passer for den belastningen; å slå på bufring for hver forespørsel kan bytte en forhandlingsfeil mot minneutmattelse.