Nuovi tentativi di autenticazione proxy e corpi di caricamento non ripetibili
Capite perché i nuovi tentativi di autenticazione possono esporre un flusso di caricamento monouso e scegliete deliberatamente un buffering limitato o contenuti ripetibili.
Una GET può autenticarsi tramite un proxy mentre una POST o PUT fallisce con un errore di corpo non ripetibile o di riavvolgimento. L'account può essere corretto: uno scambio di autenticazione può richiedere un'altra richiesta dopo che il client ha già consumato il caricamento.
| Origine del corpo | Scelta di ripetizione |
|---|---|
| Corpo piccolo e finito | Un buffer limitato può conservarne i byte. |
| File ricercabile | L'interfaccia di riavvolgimento supportata dal client può renderlo ripetibile. |
| Generatore, pipe o produttore live | Una sorgente monouso può richiedere un'altra progettazione. |
libcurl documenta callback di ricerca per usi tra cui l'autenticazione a più passaggi. Jersey offre modalità di elaborazione delle entità con buffer e suddivise, soggette al comportamento del connettore. Un esempio di connettore Jersey 2 Apache mostra l'impostazione con buffer. Nessuno dei due rende appropriati i caricamenti illimitati in memoria.
Riproducete il metodo e l'origine del corpo che falliscono. Una GET preparatoria non ha alcun caricamento da ripetere e non dimostra che un caricamento successivo condivida la sua connessione o il suo stato di autenticazione. Una nuova destinazione, un oggetto client o una policy di connessione possono cambiarlo. Un corpo basato su file e un flusso live differiscono anche quando il loro testo di esempio è lo stesso.
Se usate un buffer, definite il limite di dimensione, la posizione di archiviazione e la durata. I caricamenti simultanei moltiplicano il costo e i dati sensibili restano dove viene conservato il buffer.
Pre-autenticazione a un proxy compatibile noto può evitare una sfida iniziale. Non può escludere ogni successivo ciclo di autenticazione, reindirizzamento o connessione chiusa che potrebbe richiedere un altro tentativo.
Tenete insieme la risposta del proxy, il punto di consumo del corpo e l'errore di ripetizione. Poi distinguete la ripetizione del protocollo da un risultato applicativo incerto: un invio potrebbe essere stato elaborato prima che la sua risposta andasse persa. Seguite le regole di idempotenza della destinazione prima di inviarlo di nuovo.