Opakované pokusy o overenie cez proxy a neopakovateľné telá nahrávania
Pochopte, prečo opakované pokusy o overenie môžu odhaliť jednorazový tok nahrávania, a vedome zvoľte obmedzené bufferovanie alebo opakovateľný obsah.
GET sa môže cez proxy overiť, zatiaľ čo POST alebo PUT zlyhá s chybou neopakovateľného tela alebo prevíjania. Konto môže byť správne: overovacia výmena môže vyžadovať ďalšiu požiadavku po tom, čo klient už nahrávanie spotreboval.
| Zdroj tela | Voľba opakovania |
|---|---|
| Malé konečné telo | Obmedzený buffer môže jeho bajty uchovať. |
| Súbor s možnosťou hľadania | Klientom podporované rozhranie prevíjania ho môže urobiť opakovateľným. |
| Generátor, rúra alebo živý producent | Jednorazový zdroj môže vyžadovať iný návrh. |
libcurl dokumentuje seek callbacky pre použitia vrátane viacnásobného overovania. Jersey ponúka bufferovaný a po častiach delený režim spracovania entít v závislosti od správania konektora. Príklad konektora Jersey 2 Apache ukazuje bufferované nastavenie. Ani jedno nerobí neobmedzené nahrávania v pamäti vhodnými.
Reprodukujte metódu a zdroj tela, ktoré zlyhávajú. Prípravný GET nemá žiadne nahrávanie na opakovanie a nedokazuje, že neskoršie nahrávanie zdieľa jeho spojenie alebo stav overenia. Nový cieľ, klientsky objekt alebo zásada pripojenia to môžu zmeniť. Telo na báze súboru a živý tok sa tiež líšia, aj keď je ich ukážkový text rovnaký.
Ak bufferujete, definujte limit veľkosti, miesto uloženia a životnosť. Súbežné nahrávania znásobujú náklady a citlivé údaje zostávajú tam, kde je buffer uložený.
Predbežné overenie u známej kompatibilnej proxy môže zabrániť jednej úvodnej výzve. Nemôže však vylúčiť každé neskoršie kolo overenia, presmerovanie alebo uzavreté spojenie, ktoré môže vyžadovať ďalší pokus.
Uchovávajte odpoveď proxy, bod spotreby tela a chybu opakovania spolu. Potom rozlíšte opakovanie protokolu od neistého výsledku aplikácie: odoslanie mohlo byť spracované predtým, než sa jeho odpoveď stratila. Pred opätovným odoslaním dodržiavajte pravidlá idempotencie cieľa.