Повторни опити за прокси удостоверяване и тела за качване, които не могат да се повторят
Разберете защо повторните опити за удостоверяване могат да разкрият еднократен поток за качване и съзнателно изберете ограничено буфериране или повтарящо се съдържание.
GET може да се удостовери през прокси, докато POST или PUT се проваля с грешка за неповтарящо се тяло или за пренавиване. Акаунтът може да е правилен: обменът за удостоверяване може да изисква още една заявка, след като клиентът вече е изразходвал качването.
| Източник на тялото | Избор за повторение |
|---|---|
| Малко крайно тяло | Ограничен буфер може да запази байтовете му. |
| Файл с търсене | Поддържаният от клиента интерфейс за пренавиване може да го направи повтарящо се. |
| Генератор, канал или жив производител | Еднократният източник може да изисква друг дизайн. |
libcurl документира seek callback-и за употреби, включително многостъпково удостоверяване. Jersey предлага буфериран и раздробен режим на обработка на обекти в зависимост от поведението на конектора. Пример с конектор Jersey 2 Apache показва буферираната настройка. Нито един от тях не прави неограничените качвания в паметта подходящи.
Възпроизведете метода и източника на тялото, които се провалят. Подготвителният GET няма качване за повторение и не доказва, че по-късно качване споделя неговата връзка или състояние на удостоверяване. Нова дестинация, клиентски обект или политика за връзки може да промени това. Тяло, базирано на файл, и жив поток също се различават, дори когато примерният им текст е еднакъв.
Ако буферирате, определете лимита на размера, мястото за съхранение и живота му. Едновременните качвания умножават разходите, а чувствителните данни остават там, където се пази буферът.
Предварително удостоверяване към известен съвместим прокси може да избегне едно първоначално предизвикателство. То не може да изключи всеки следващ кръг на удостоверяване, пренасочване или затворена връзка, които може да изискват нов опит.
Дръжте отговора на проксито, точката на изразходване на тялото и грешката при повторение заедно. След това разграничете повторението на протокола от несигурен резултат на приложението: подаване може да е било обработено, преди отговорът му да се загуби. Следвайте правилата за идемпотентност на дестинацията, преди да го изпратите отново.