Buforowanie wysyłania w Jersey 2 na potrzeby ponownych prób uwierzytelniania przez proxy

Uczyń jednostkę żądania Jersey 2 ze złączem Apache powtarzalną, gdy negocjacja uwierzytelniania musi ponownie wysłać przesyłkę.

Wysyłka ponawiana po wyzwaniu proxy znowu potrzebuje swojej treści. Dla złącza Apache w Jersey 2 wybierz przetwarzanie buforowanej jednostki w konfiguracji, z której budowany jest ten klient:

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

Wykonaj wysyłkę przez powstałego klienta. Te typy pochodzą z pakietów Jersey client i Apache-connector; ustawienie nieużywanej konfiguracji nie wpłynęłoby na żądanie.

Złącze opakowuje buforowaną jednostkę w BufferedHttpEntity firmy Apache. Jego niebuforowana jednostka strumieniowa nie jest powtarzalna. Buforowanie daje przepływowi uwierzytelniania bajty, które może wysłać ponownie, zamiast ponownie czytać zużyty producent.

Nie gwarantuje to, że uwierzytelnianie zakończy się po jednym 407. Niektóre schematy uzasadnionie wymagają kilku wymian, więc przejrzyj całą negocjację, zanim uznasz kolejne wyzwanie za utracony stan.

Utrzymaj rozmiar treści w budżecie pamięci. Duża wysyłka strumieniowa wymaga strategii powtórzenia dostosowanej do tego obciążenia; włączenie buforowania dla każdego żądania może zamienić błąd negocjacji na wyczerpanie pamięci.

Powiązane artykuły