En upload, der forsøges igen efter en proxy-udfordring, har brug for sin krop igen. Vælg bufret entitetsbehandling i den konfiguration, der bruges til at bygge klienten, for Jersey 2's Apache-connector:

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

Udfør uploadet gennem den resulterende klient. Disse typer kommer fra Jersey client- og Apache-connector-pakkerne; en ubrugt konfiguration ville ikke påvirke anmodningen.

Connectoren pakker en bufret entitet ind i Apaches BufferedHttpEntity. Dens ubufrede streaming-entitet kan ikke gentages. Bufring giver godkendelsesforløbet bytes, det kan sende igen i stedet for at læse en forbrugt producer på ny.

Det garanterer ikke, at godkendelsen slutter efter én 407. Nogle skemaer kræver med rette flere udvekslinger, så undersøg hele forhandlingen, før du behandler endnu en udfordring som tabt tilstand.

Hold kropsstørrelsen inden for hukommelsesbudgettet. Et stort streaming-upload kræver en genafspilningsstrategi, der passer til den belastning; at slå bufring til for hver anmodning kan bytte en forhandlingsfejl for hukommelsesudmattelse.

Relaterede artikler