Et GET kan godkende gennem en proxy, mens et POST eller PUT fejler med en fejl om ikke-gentagelig body eller tilbagespoling. Kontoen kan være korrekt: en godkendelsesudveksling kan kræve endnu en anmodning, efter at klienten allerede har forbrugt uploadet.

Body-kildeValg af gentagelse
Lille endelig bodyEn begrænset buffer kan beholde dens bytes.
Søgbar filKlientens understøttede tilbagespolingsgrænseflade kan gøre den gentagelig.
Generator, pipe eller live-producentEn engangskilde kan kræve et andet design.

libcurl dokumenterer seek-callbacks til anvendelser, herunder godkendelse i flere passager. Jersey tilbyder bufret og opdelt entity-behandling afhængigt af connector-adfærd. Et eksempel på Jersey 2 Apache-connector viser den buffrede indstilling. Ingen af dem gør ubegrænsede uploads i hukommelsen hensigtsmæssige.

Genskab den metode og body-kilde, der fejler. Et forberedende GET har intet upload at gentage og beviser ikke, at et senere upload deler dets forbindelse eller godkendelsestilstand. En ny destination, klientobjekt eller forbindelsespolitik kan ændre det. En filbaseret body og en live-strøm er også forskellige, selv når deres eksempeltekst er den samme.

Hvis du bufferer, skal du definere størrelsesgrænse, lagerplacering og levetid. Samtidige uploads mangedobler omkostningerne, og følsomme data bliver, hvor bufferen opbevares.

Forudgående godkendelse til en kendt kompatibel proxy kan undgå én indledende udfordring. Det kan ikke udelukke enhver senere godkendelsesrunde, omdirigering eller lukket forbindelse, som kan kræve endnu et forsøg.

Hold proxy-svaret, body-forbrugspunktet og gentagelsesfejlen sammen. Skeln derefter protokolgentagelse fra et usikkert applikationsresultat: en indsendelse kan være blevet behandlet, før dens svar gik tabt. Følg destinationens idempotensregler, før du sender den igen.

Relaterede artikler