Pausas de carga HTTP y Expect: 100-continue
Reconozca el intercambio Expect: 100-continue y distinga su breve punto de decisión de una carga que se quedó detenida durante la transferencia de datos.
La conexión se abre. Las cabeceras de la petición salen. Parece que el archivo no avanza. Una explicación es que el cliente espera una respuesta a Expect: 100-continue antes de enviar su cuerpo.
El mecanismo permite al receptor rechazar una petición a partir de sus cabeceras antes de que se envíe una carga potencialmente grande. La secuencia exitosa habitual es:
request headers → 100 Continue → request body → final response100 es informativo: permite al cliente continuar, pero no significa que el archivo se haya guardado ni que la operación de la aplicación haya tenido éxito. Un Git push que devuelve HTTP 417 es un caso concreto de expectativa fallida.
Determine qué respuesta recibió el cliente
| Observación | Significado que investigar |
|---|---|
| 100 Continue | El cliente puede continuar con el cuerpo |
| Un rechazo final antes del cuerpo | La operación se rechazó en la fase de cabeceras |
| Ninguna respuesta intermedia esperada | La política de espera del cliente y el tratamiento en esa ruta |
curl ofrece un ajuste de espera específico para expect-continue. Si esa espera de libcurl expira sin la respuesta esperada, envía el cuerpo de todos modos; la expiración no es automáticamente un fallo de toda la transferencia. El ajuste es independiente del tiempo permitido para la transferencia completa. Aumentar este último puede dejar sin explicar la misma pausa inicial.
Identifique también qué conversación HTTP transporta Expect. Con un CONNECT normal a un destino HTTPS, el intercambio de carga del sitio web está dentro de TLS; el proxy de reenvío no inspecciona simplemente su cabecera de expectativa interna. Una ruta de interceptación o de reenvío en texto plano es distinta.
Eliminar la expectativa puede ser una elección deliberada de compatibilidad, pero significa que el cliente podría empezar a enviar un cuerpo grande antes de enterarse de un rechazo temprano. Compare ese comportamiento con el requisito real. No describa una solución histórica para un proxy antiguo como una instrucción universal de quitar la cabecera de cada carga.