GET може автентифікуватися через проксі, тоді як POST або PUT завершується помилкою неповторюваного тіла чи перемотування. Обліковий запис може бути правильним: обмін автентифікації може вимагати ще одного запиту після того, як клієнт уже витратив завантаження.

Джерело тілаВибір повторення
Мале скінченне тілоОбмежений буфер може зберегти його байти.
Файл із можливістю пошукуІнтерфейс перемотування, який підтримує клієнт, може зробити його повторюваним.
Генератор, канал або живий виробникОдноразовому джерелу може знадобитися інша архітектура.

libcurl документує зворотні виклики пошуку для застосувань, зокрема багатоетапної автентифікації. Jersey пропонує буферизований і фрагментований режими обробки сутностей залежно від поведінки конектора. Приклад конектора Jersey 2 Apache показує буферизоване налаштування. Жоден із них не робить необмежені завантаження в пам'яті доречними.

Відтворіть метод і джерело тіла, які зазнають збою. Підготовчий GET не має завантаження для повторення і не доводить, що подальше завантаження поділяє його з'єднання або стан автентифікації. Нове призначення, клієнтський об'єкт або політика з'єднань можуть це змінити. Тіло на основі файлу та живий потік теж різняться, навіть коли їхній зразковий текст однаковий.

Якщо ви буферизуєте, задайте межу розміру, місце зберігання і час життя. Одночасні завантаження множать витрати, а конфіденційні дані залишаються там, де зберігається буфер.

Попередня автентифікація на відомому сумісному проксі може уникнути одного початкового виклику. Однак вона не може виключити кожен подальший раунд автентифікації, перенаправлення або закрите з'єднання, які можуть вимагати ще однієї спроби.

Тримайте разом відповідь проксі, точку витрати тіла та помилку повторення. Потім відрізняйте повторення протоколу від невизначеного результату застосунку: надсилання могло бути оброблене до втрати його відповіді. Перед повторним надсиланням дотримуйтеся правил ідемпотентності призначення.

Схожі статті