Буферызацыя загрузкі ў Jersey 2 для паўторных спроб аўтэнтыфікацыі праз проксі

Зрабіце цела запыту Jersey 2 з Apache-connector паўторным, калі ўзгадненне аўтэнтыфікацыі патрабуе паўторнай адпраўкі загрузкі.

Загрузка, якая паўтараецца пасля выкліку проксі, зноў патрабуе свайго цела. Для Apache connector у Jersey 2 выберыце апрацоўку буфераванага цела ў канфігурацыі, якая выкарыстоўваецца для стварэння гэтага кліента:

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

Выканайце загрузку праз атрыманы кліент. Гэтыя тыпы паходзяць з пакетаў Jersey client і Apache-connector; наладжванне невыкарыстоўванай канфігурацыі не паўплывала б на запыт.

Connector абгортвае буфераванае цела ў BufferedHttpEntity ад Apache. Яго небуфераванае патокавае цела не паўтараецца. Буферызацыя дае працэсу аўтэнтыфікацыі байты, якія ён можа адправіць зноў, замест паўторнага чытання ўжо спажытага генератара.

Гэта не гарантуе, што аўтэнтыфікацыя скончыцца пасля аднаго 407. Некаторыя схемы законна патрабуюць некалькіх абменаў, таму праверце ўсё ўзгадненне, перш чым лічыць чарговы выклік страчаным станам.

Трымайце памер цела ў межах бюджэту памяці. Вялікая патокавая загрузка патрабуе стратэгіі паўтору, якая адпавядае такой нагрузцы; уключэнне буферызацыі для кожнага запыту можа абмяняць збой узгаднення на вычарпанне памяці.

Падобныя артыкулы