Reintentos de autenticación del proxy y cuerpos de carga no repetibles
Comprenda por qué los reintentos de autenticación pueden exponer un flujo de carga de un solo uso y elija deliberadamente un búfer limitado o contenido repetible.
Una solicitud GET puede autenticarse a través de un proxy mientras que un POST o PUT falla con un error de cuerpo no repetible o de rebobinado. La cuenta puede ser correcta: un intercambio de autenticación puede requerir otra solicitud después de que el cliente ya haya consumido la carga.
| Origen del cuerpo | Opción de repetición |
|---|---|
| Cuerpo pequeño y finito | Un búfer limitado puede conservar sus bytes. |
| Archivo con búsqueda | La interfaz de rebobinado compatible con el cliente puede hacerlo repetible. |
| Generador, tubería o productor en vivo | Una fuente de un solo uso puede requerir otro diseño. |
libcurl documenta devoluciones de llamada de búsqueda para usos como la autenticación en varias pasadas. Jersey ofrece modos de procesamiento de entidades con búfer y fragmentados sujetos al comportamiento del conector. Un ejemplo de conector Jersey 2 Apache muestra la configuración con búfer. Ninguno de los dos hace apropiadas las cargas ilimitadas en memoria.
Reproduzca el método y el origen del cuerpo que fallan. Un GET preparatorio no tiene ninguna carga que repetir y no demuestra que una carga posterior comparta su conexión o su estado de autenticación. Un destino, objeto de cliente o política de conexión nuevos pueden cambiarlo. Un cuerpo basado en archivo y un flujo en vivo también difieren aunque su texto de muestra sea el mismo.
Si usa búfer, defina su límite de tamaño, ubicación de almacenamiento y vida útil. Las cargas simultáneas multiplican el costo y los datos sensibles permanecen donde se guarde el búfer.
Autenticación previa a un proxy compatible conocido puede evitar un desafío inicial. No puede excluir cada ronda de autenticación, redirección o conexión cerrada posterior que pueda exigir otro intento.
Mantenga juntos la respuesta del proxy, el punto de consumo del cuerpo y el error de repetición. Después distinga la repetición del protocolo de un resultado de aplicación incierto: un envío puede haberse procesado antes de que se perdiera su respuesta. Siga las reglas de idempotencia del destino antes de enviarlo de nuevo.