Nouvelles tentatives d'authentification via proxy et corps d'envoi non rejouables
Comprenez pourquoi les nouvelles tentatives d'authentification peuvent exposer un flux d'envoi à usage unique, et choisissez délibérément une mise en tampon bornée ou un contenu rejouable.
Une requête GET peut s'authentifier via un proxy alors qu'un POST ou un PUT échoue avec une erreur de corps non rejouable ou de rembobinage. Le compte peut être correct : un échange d'authentification peut exiger une autre requête après que le client a déjà consommé l'envoi.
| Source du corps | Choix de rejeu |
|---|---|
| Petit corps fini | Une mémoire tampon bornée peut conserver ses octets. |
| Fichier recherchable | L'interface de rembobinage prise en charge par le client peut le rendre rejouable. |
| Générateur, tube ou producteur en direct | Une source à usage unique peut exiger une autre conception. |
libcurl documente des rappels de recherche pour des usages incluant l'authentification en plusieurs passes. Jersey propose des modes de traitement d'entité tamponné et fragmenté selon le comportement du connecteur. Un exemple de connecteur Jersey 2 Apache montre le réglage tamponné. Ni l'un ni l'autre ne rend appropriés les envois illimités en mémoire.
Reproduisez la méthode et la source de corps qui échouent. Un GET préparatoire n'a aucun envoi à rejouer et ne prouve pas qu'un envoi ultérieur partage sa connexion ou son état d'authentification. Une nouvelle destination, un objet client ou une politique de connexion peuvent changer cela. Un corps sauvegardé par fichier et un flux en direct diffèrent aussi même lorsque leur texte d'exemple est identique.
Si vous mettez en tampon, définissez sa limite de taille, son emplacement de stockage et sa durée de vie. Les envois simultanés multiplient le coût, et les données sensibles restent là où le tampon est conservé.
Pré-authentification auprès d'un proxy compatible connu peut éviter un premier défi. Elle ne peut pas exclure chaque nouvelle manche d'authentification, redirection ou connexion fermée ultérieure qui pourrait exiger une autre tentative.
Gardez ensemble la réponse du proxy, le point de consommation du corps et l'erreur de rejeu. Distinguez ensuite le rejeu de protocole d'un résultat applicatif incertain : une soumission peut avoir été traitée avant la perte de sa réponse. Suivez les règles d'idempotence de la destination avant de la renvoyer.