Ponowne próby uwierzytelniania przez proxy i niepowtarzalne treści przesyłania
Zrozum, dlaczego ponowne próby uwierzytelniania mogą ujawnić jednorazowy strumień przesyłania, i świadomie wybierz ograniczone buforowanie lub powtarzalną treść.
Żądanie GET może uwierzytelnić się przez proxy, podczas gdy POST lub PUT kończy się błędem niepowtarzalnej treści lub przewijania. Konto może być poprawne: wymiana uwierzytelniania może wymagać kolejnego żądania po tym, jak klient już zużył przesyłanie.
| Źródło treści | Wybór powtórzenia |
|---|---|
| Mała skończona treść | Ograniczony bufor może zachować jej bajty. |
| Plik z możliwością wyszukiwania | Interfejs przewijania obsługiwany przez klienta może uczynić ją powtarzalną. |
| Generator, potok lub producent na żywo | Jednorazowe źródło może wymagać innego projektu. |
libcurl dokumentuje wywołania zwrotne wyszukiwania dla zastosowań, w tym uwierzytelniania wieloetapowego. Jersey oferuje buforowane i dzielone tryby przetwarzania encji, zależnie od zachowania łącznika. Przykład łącznika Jersey 2 Apache pokazuje ustawienie buforowane. Żadne z nich nie czyni nieograniczonych przesyłań w pamięci właściwymi.
Odtwórz metodę i źródło treści, które zawodzą. Przygotowawcze GET nie ma przesyłania do powtórzenia i nie dowodzi, że późniejsze przesyłanie dzieli jego połączenie lub stan uwierzytelniania. Nowy cel, obiekt klienta lub polityka połączeń mogą to zmienić. Treść oparta na pliku i strumień na żywo również się różnią, nawet gdy ich przykładowy tekst jest taki sam.
Jeśli buforujesz, zdefiniuj limit rozmiaru, miejsce przechowywania i czas życia. Równoczesne przesyłania mnożą koszty, a wrażliwe dane pozostają tam, gdzie przechowywany jest bufor.
Uwierzytelnianie wstępne do znanego zgodnego proxy może uniknąć jednego początkowego wyzwania. Nie może jednak wykluczyć każdej późniejszej rundy uwierzytelniania, przekierowania lub zamkniętego połączenia, które może wymagać kolejnej próby.
Trzymaj razem odpowiedź proxy, punkt zużycia treści i błąd powtórzenia. Następnie odróżnij powtórzenie protokołu od niepewnego wyniku aplikacji: przesłanie mogło zostać przetworzone, zanim utracono jego odpowiedź. Przed ponownym wysłaniem przestrzegaj zasad idempotentności celu.