Resumen

  • Expect: 100-continue comunica que el cliente desea pausar el cuerpo para que método, destino y cabeceras puedan producir primero un rechazo final.
  • Un 100 solo anima a continuar el envío. El origen aún debe emitir el estado final y un intermediario puede generar la respuesta provisional sin hablar por el origen.
  • El cliente puede abandonar la espera y enviar el cuerpo; así evita el bloqueo cuando un salto antiguo o defectuoso no transporta respuestas informativas.

La parte decidible llegaba antes que la cara

HTTP coloca línea de petición y cabeceras antes del contenido opcional. Un servidor puede reconocer autorización insuficiente, método prohibido o destino inválido sin recibir un archivo de gran tamaño.

Enviar todo desperdicia capacidad si la conclusión será 401 o 405. Pero detenerse sin señal compartida crea un bloqueo: el cliente espera permiso y el servidor espera cuerpo. 100 Continue ocupó ese espacio.

El RFC 2068 definió en 1997 el estado informativo y reglas complejas de compatibilidad. Un intermediario HTTP/1.0 podía no transmitir 100, por lo que la versión y los temporizadores formaban parte del problema desde el comienzo.

Hacer visible la intención de esperar

El RFC 2616 incorporó Expect y el valor 100-continue. El servidor pudo distinguir al cliente que retenía el contenido del que enviaba cabeceras y cuerpo sin pausa.

Quien vaya a esperar debe declararlo y no puede declarar la expectativa si no hay contenido. Si algunos bytes ya llegaron, el servidor puede omitir un 100 que dejó de ser útil.

Ante cabeceras completas de HTTP/1.1, cuerpo anunciado y expectativa presente, el origen debe actuar enseguida. Envía un estado final si puede decidirlo con esos datos; de lo contrario, envía 100 sin esperar el cuerpo. La invitación no puede depender del mismo objeto que mantiene bloqueado al emisor.

Continuar no equivale a aceptar

Los estados 1xx son informativos. No completan la petición. Después de 100, el servidor todavía debe recibir y procesar el contenido y devolver un estado final, salvo cierre prematuro.

La autorización es estrecha: las cabeceras vistas no justifican detener el transporte. No certifica identidad, validez, almacenamiento, ejecución ni éxito. El cuerpo puede fallar al analizarse, la capacidad puede agotarse y la autorización puede depender de él.

Por eso el intercambio no es una preparación transaccional ni un commit en dos fases. La respuesta provisional administra una inversión de red, no el resultado semántico del método.

El proxy podía invitar sin poder aceptar

Un proxy puede emitir un estado final que conoce o reenviar cabeceras al origen. Si sabe que el siguiente salto es antiguo, a veces puede generar 100 para que el cliente avance.

Ese 100 demuestra disposición del salto, no recepción ni aceptación del origen. La telemetría que pierde el emisor de cada respuesta convierte permiso local en una falsa declaración extremo a extremo.

El 417 Expectation Failed dice que la cadena no satisface la expectativa. Reintentar sin ella elimina la optimización, pero no convierte en segura la repetición de una operación con efectos. Sigue siendo necesario saber qué alcanzó el origen.

El silencio no adquirió derecho de veto

Los RFC 7231 y RFC 9110 conservan la salida unilateral: no hay espera obligatoria de duración fija y el cliente puede comenzar el cuerpo sin recibir 100. No debería esperar indefinidamente.

Un salto HTTP/1.0 puede tragarse el estado; un servidor puede haber empezado a leer. La pausa limitada transforma un posible ahorro en optimización, no en dependencia de negociación perfecta. El cliente conserva el control sobre cuándo el coste de esperar supera al de enviar.

No existe un umbral universal de tamaño o latencia. En cuerpos pequeños, la ida y vuelta adicional puede costar más que el ahorro. Las normas fijan responsabilidades y progreso, no una recomendación de rendimiento para toda ruta.

Un final temprano deja bytes por ordenar

El servidor puede responder definitivamente mientras el cuerpo sigue en vuelo. Debe cerrar la conexión o consumir y descartar el resto de manera que los mensajes posteriores conserven su encuadre.

El veredicto de aplicación y el destino de la conexión son hechos distintos. Si quedan bytes y ambos extremos discrepan sobre su significado, una conexión reutilizada puede confundir contenido residual con otra petición.

Fuentes y límites

El conjunto cerrado es RFC 2068, RFC 2616, RFC 7231 y RFC 9110. Establece evolución y semántica, no uso actual, tiempos por defecto, cumplimiento de proxies ni ahorro medido.