Bufring av en Jersey 2-opplasting for nye forsøk med proxy-autentisering
Gjør en Jersey 2-forespørselsentitet med Apache-kobling gjentakbar når autentiseringsforhandlingen må sende opplastingen på nytt.
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 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 du får. Disse typene kommer fra pakkene Jersey client og Apache-connector; en ubrukt konfigurasjon ville ikke påvirket forespørselen.
Koblingen pakker en bufret entitet inn i Apaches BufferedHttpEntity. Den ubufrede strømmeentiteten kan ikke gjentas. Bufring gir autentiseringsflyten bytes den kan sende på nytt i stedet for å lese en oppbrukt produsent om igjen.
Det garanterer ikke at autentiseringen avsluttes etter én 407. Enkelte skjemaer krever med rette flere utvekslinger, så undersøk hele forhandlingen før du ser på nok en utfordring som tapt tilstand.
Hold kroppsstørrelsen innenfor minnebudsjettet. En stor strømmeopplasting trenger en gjentakelsesstrategi tilpasset den belastningen; å slå på bufring for hver forespørsel kan bytte en forhandlingsfeil mot minneutmattelse.