Opakované pokusy o ověření přes proxy a těla nahrávání, která nelze opakovat
Pochopte, proč mohou opakované pokusy o ověření odhalit jednorázový tok nahrávání, a vědomě zvolte omezené bufferování nebo opakovatelný obsah.
GET se může přes proxy ověřit, zatímco POST nebo PUT selže s chybou neopakovatelného těla nebo převinutí. Účet může být správný: ověřovací výměna může vyžadovat další požadavek poté, co klient už nahrávání spotřeboval.
| Zdroj těla | Volba opakování |
|---|---|
| Malé konečné tělo | Omezený buffer může jeho bajty uchovat. |
| Soubor s možností hledání | Klientem podporované rozhraní převinutí jej může učinit opakovatelným. |
| Generátor, roura nebo živý producent | Jednorázový zdroj může vyžadovat jiný návrh. |
libcurl dokumentuje seek callbacky pro použití včetně vícenásobného ověřování. Jersey nabízí bufferovaný a po částech dělený režim zpracování entit v závislosti na chování konektoru. Příklad konektoru Jersey 2 Apache ukazuje bufferované nastavení. Ani jedno nečiní neomezená nahrávání v paměti vhodnými.
Reprodukujte metodu a zdroj těla, které selhávají. Přípravný GET nemá žádné nahrávání k opakování a nedokazuje, že pozdější nahrávání sdílí jeho spojení nebo stav ověření. Nový cíl, klientský objekt nebo zásada připojení to mohou změnit. Tělo na bázi souboru a živý proud se také liší, i když je jejich ukázkový text stejný.
Pokud bufferujete, definujte limit velikosti, místo uložení a životnost. Souběžná nahrávání násobí náklady a citlivá data zůstávají tam, kde je buffer uložen.
Předběžné ověření u známé kompatibilní proxy může zabránit jedné úvodní výzvě. Nemůže však vyloučit každé pozdější kolo ověřování, přesměrování nebo uzavřené spojení, které může vyžadovat další pokus.
Uchovávejte odpověď proxy, bod spotřeby těla a chybu opakování pohromadě. Poté rozlište opakování protokolu od nejistého výsledku aplikace: odeslání mohlo být zpracováno dříve, než se jeho odpověď ztratila. Před opětovným odesláním dodržujte pravidla idempotence cíle.