Herhaalde proxy-authenticaties en niet-herhaalbare upload-bodies
Begrijp waarom herhaalde authenticatiepogingen een eenmalige uploadstream kunnen blootleggen, en kies bewust begrensde buffering of herhaalbare inhoud.
Een GET kan zich via een proxy authenticeren terwijl een POST of PUT mislukt met een fout over een niet-herhaalbare body of terugspoelen. Het account kan correct zijn: een authenticatie-uitwisseling kan nog een verzoek vereisen nadat de client de upload al heeft verbruikt.
| Bron van de body | Keuze voor herhaling |
|---|---|
| Kleine eindige body | Een begrensde buffer kan de bytes ervan bewaren. |
| Doorzoekbaar bestand | De door de client ondersteunde terugspoelinterface kan hem herhaalbaar maken. |
| Generator, pijplijn of live-producent | Een eenmalige bron kan een ander ontwerp vereisen. |
libcurl documenteert zoek-callbacks voor toepassingen, waaronder authenticatie in meerdere passes. Jersey biedt gebufferde en opgesplitste entiteitsverwerkingsmodi, afhankelijk van het gedrag van de connector. Een voorbeeld van de Jersey 2 Apache-connector toont de gebufferde instelling. Geen van beide maakt onbegrensde uploads in het geheugen passend.
Reproduceer de methode en de body-bron die mislukken. Een voorbereidende GET heeft geen upload om te herhalen, en bewijst niet dat een latere upload zijn verbinding of authenticatiestatus deelt. Een nieuwe bestemming, clientobject of verbindingsbeleid kan dat veranderen. Een bestandsgebaseerde body en een live stream verschillen ook, zelfs wanneer hun voorbeeldtekst dezelfde is.
Als je buffert, definieer de groottelimiet, de opslaglocatie en de levensduur. Gelijktijdige uploads vermenigvuldigen de kosten, en gevoelige gegevens blijven waar de buffer wordt bewaard.
Voorafgaande authenticatie bij een bekende compatibele proxy kan één eerste uitdaging vermijden. Het kan niet elke latere authenticatieronde, omleiding of gesloten verbinding uitsluiten die een nieuwe poging kan vereisen.
Houd het proxy-antwoord, het punt waar de body wordt verbruikt en de herhaalfout bij elkaar. Onderscheid daarna protocolherhaling van een onzeker applicatieresultaat: een inzending kan zijn verwerkt voordat het antwoord verloren ging. Volg de idempotentieregels van de bestemming voordat je het opnieuw verstuurt.