Repetiții ale autentificării prin proxy și corpuri de încărcare nerepetabile
Înțelegeți de ce repetițiile autentificării pot expune un flux de încărcare de unică folosință și alegeți deliberat o memorare tampon limitată sau conținut repetabil.
Un GET se poate autentifica printr-un proxy în timp ce un POST sau PUT eșuează cu o eroare de corp nerepetabil sau de derulare inversă. Contul poate fi corect: un schimb de autentificare poate necesita încă o cerere după ce clientul a consumat deja încărcarea.
| Sursa corpului | Opțiunea de repetare |
|---|---|
| Corp mic finit | Un tampon limitat îi poate păstra octeții. |
| Fișier căutabil | Interfața de derulare inversă acceptată de client îl poate face repetabil. |
| Generator, conductă sau producător live | O sursă de unică folosință poate necesita alt proiect. |
libcurl documentează apeluri inverse de căutare pentru utilizări, inclusiv autentificarea în mai multe treceri. Jersey oferă moduri de procesare a entităților cu tampon și segmentate, în funcție de comportamentul conectorului. Un exemplu de conector Jersey 2 Apache arată setarea cu tampon. Niciunul nu face adecvate încărcările nelimitate în memorie.
Reproduceți metoda și sursa corpului care eșuează. Un GET pregătitor nu are nicio încărcare de repetat și nu dovedește că o încărcare ulterioară îi împărtășește conexiunea sau starea de autentificare. O destinație, un obiect client sau o politică de conexiune noi pot schimba asta. Un corp bazat pe fișier și un flux live diferă și ele chiar când textul lor de probă este același.
Dacă folosiți memorare tampon, definiți limita de dimensiune, locația de stocare și durata de viață. Încărcările simultane multiplică costul, iar datele sensibile rămân oriunde este păstrat tamponul.
Autentificare prealabilă la un proxy compatibil cunoscut poate evita o provocare inițială. Nu poate exclude fiecare rundă de autentificare, redirecționare sau conexiune închisă ulterioară care ar putea cere o altă încercare.
Păstrați împreună răspunsul proxy-ului, punctul de consum al corpului și eroarea de repetare. Apoi distingeți repetarea protocolului de un rezultat incert al aplicației: o trimitere poate fi fost procesată înainte de pierderea răspunsului. Urmați regulile de idempotență ale destinației înainte de a o trimite din nou.