Запыт GET можа прайсці аўтэнтыфікацыю праз проксі, а POST або PUT церпіць няўдачу з памылкай непаўторнага цела або перамоткі. Уліковы запіс можа быць правільным: абмен аўтэнтыфікацыі можа патрабаваць яшчэ аднаго запыту пасля таго, як кліент ужо спажыў загрузку.

Крыніца целаВыбар паўтору
Малое канчатковае целаАбмежаваны буфер можа захаваць яго байты.
Файл з магчымасцю пошукуІнтэрфейс перамоткі, які падтрымлівае кліент, можа зрабіць яго паўторным.
Генератар, канал або жывы вырабнікАднаразовай крыніцы можа спатрэбіцца іншая архітэктура.

libcurl дакументуе seek-калбэкі для выкарыстанняў, уключаючы шматпраходную аўтэнтыфікацыю. Jersey прапануе буфераваныя і раздзеленыя на часткі рэжымы апрацоўкі сутнасцей у залежнасці ад паводзін канэктара. Прыклад канэктара Jersey 2 Apache паказвае буфераваную наладу. Ні адзін з іх не робіць неабмежаваныя загрузкі ў памяці мэтазгоднымі.

Узнавіце метад і крыніцу цела, якія церпяць няўдачу. Падрыхтоўчы GET не мае загрузкі для паўтору і не даказвае, што наступная загрузка падзяляе яго злучэнне або стан аўтэнтыфікацыі. Новы пункт прызначэння, кліенцкі аб'ект або палітыка злучэнняў могуць гэта змяніць. Цела на аснове файла і жывы паток таксама розняцца, нават калі іх узорны тэкст аднолькавы.

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

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

Трымайце адказ проксі, пункт спажывання цела і памылку паўтору разам. Затым адрозніце паўтор пратаколу ад няпэўнага выніку праграмы: заяўка магла быць апрацавана да таго, як яе адказ быў страчаны. Перад паўторнай адпраўкай выконвайце правілы ідэмпатэнтнасці пункта прызначэння.

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