Erneute Proxy-Authentifizierungen und nicht wiederholbare Upload-Bodys
Verstehen Sie, warum erneute Authentifizierungsversuche einen einmaligen Upload-Stream offenlegen können, und wählen Sie bewusst begrenzte Pufferung oder wiederholbaren Inhalt.
Ein GET kann sich über einen Proxy authentifizieren, während ein POST oder PUT mit einem Fehler wegen eines nicht wiederholbaren Bodys oder Rückspulens scheitert. Das Konto kann korrekt sein: Ein Authentifizierungsaustausch kann eine weitere Anfrage erfordern, nachdem der Client den Upload bereits verbraucht hat.
| Body-Quelle | Wiederholungswahl |
|---|---|
| Kleiner endlicher Body | Ein begrenzter Puffer kann seine Bytes halten. |
| Durchsuchbare Datei | Die vom Client unterstützte Rückspul-Schnittstelle kann ihn wiederholbar machen. |
| Generator, Pipe oder Live-Erzeuger | Eine Einmalquelle kann ein anderes Design erfordern. |
libcurl dokumentiert Seek-Callbacks für Anwendungen einschließlich mehrstufiger Authentifizierung. Jersey bietet gepufferte und aufgeteilte Entity-Verarbeitungsmodi, abhängig vom Verhalten des Connectors. Ein Beispiel für den Jersey-2-Apache-Connector zeigt die gepufferte Einstellung. Keines von beiden macht unbegrenzte In-Memory-Uploads angemessen.
Reproduzieren Sie die Methode und die Body-Quelle, die scheitern. Ein vorbereitendes GET hat keinen Upload zum Wiederholen und belegt nicht, dass ein späterer Upload seine Verbindung oder seinen Authentifizierungszustand teilt. Ein neues Ziel, Client-Objekt oder eine Verbindungsrichtlinie kann das ändern. Ein dateigestützter Body und ein Live-Stream unterscheiden sich ebenfalls, selbst wenn ihr Beispieltext gleich ist.
Wenn Sie puffern, legen Sie Größenlimit, Speicherort und Lebensdauer fest. Parallele Uploads vervielfachen die Kosten, und sensible Daten bleiben, wo der Puffer aufbewahrt wird.
Vorab-Authentifizierung bei einem bekannten kompatiblen Proxy kann eine anfängliche Challenge vermeiden. Sie kann jedoch nicht jede spätere Authentifizierungsrunde, Weiterleitung oder geschlossene Verbindung ausschließen, die einen weiteren Versuch verlangen könnte.
Halten Sie Proxy-Antwort, den Punkt des Body-Verbrauchs und den Wiederholungsfehler zusammen. Unterscheiden Sie dann Protokollwiederholung von einem unsicheren Anwendungsergebnis: Eine Übermittlung kann verarbeitet worden sein, bevor ihre Antwort verloren ging. Befolgen Sie die Idempotenzregeln des Ziels, bevor Sie sie erneut senden.