Códigos de estado informativos 1xx

Qué es una respuesta provisional

Cualquier otra familia de estado termina el intercambio. Un 200, un 404 o un 502 son la última palabra del servidor sobre esa petición. Un 1xx es distinto: el servidor envía la línea de estado y cualquier cabecera, mantiene la conexión abierta y envía una segunda respuesta más tarde. El RFC 9110 exige que los clientes sean capaces de leer una o más respuestas 1xx antes de la final, y permite que cualquier cliente que no entienda un código 1xx concreto lo ignore.

La respuesta provisional se descarta en cuanto llega la final, así que la mayoría de las herramientas nunca la muestran. El panel de red de tu navegador, el registro de acceso de tu servidor web y una comprobación de monitorización reportan todos el estado final. La respuesta provisional hizo su trabajo a nivel de transporte y desapareció.

Los códigos 1xx que te puedes encontrar

• 100 Continue. El cliente envió las cabeceras de la petición con Expect: 100-continue y se detuvo antes de enviar un cuerpo grande. Un 100 significa "las cabeceras están bien, envía el cuerpo". Si el servidor fuera a rechazar la petición de todas formas, puede responder con un error final en su lugar y el cliente nunca desperdicia ancho de banda subiendo la carga. Este es el único código 1xx que hace un trabajo útil en sitios normales, normalmente detrás de subidas de archivos grandes y clientes de API como curl.
• 101 Switching Protocols. El cliente pidió cambiar de protocolo con una cabecera Upgrade y el servidor accedió. Es el resultado normal y correcto de un saludo de WebSocket, así que un 101 en un registro por lo general es buena señal, no una incidencia.
• 102 Processing. Definido por la especificación WebDAV para peticiones de larga duración, para que el cliente sepa que el servidor no se ha bloqueado. Rara vez se implementa fuera de WebDAV y es poco probable que te lo encuentres en un sitio web normal.
• 103 Early Hints. El servidor envía cabeceras Link pronto, antes de haber terminado de generar la página, para que el navegador pueda empezar a precargar hojas de estilo, fuentes o scripts mientras el HTML todavía se está produciendo. Es una función de rendimiento, no una señal de error, y normalmente la activas de forma deliberada en la CDN o en el origen.

Por qué un 1xx no es algo que arreglar

Un 1xx por sí solo no lleva ninguna culpa. No existe eso de una página que "devuelve 100" o "devuelve 101" de la forma en que una página puede devolver 404. Si tienes un problema y hay un 1xx en algún punto del intercambio, la información interesante siempre es el código de estado final que lo siguió, o el hecho de que no llegara ninguna respuesta final en absoluto.

Los fallos reales cerca de un 1xx aparecen como un bloqueo o un error final y no como el propio 1xx:

• Un proxy o balanceador de carga antiguo que no reenvía las respuestas provisionales, así que un cliente esperando un 100 Continue se queda bloqueado hasta que se dispara su propio tiempo de espera.
• Una actualización de WebSocket que nunca llega a un 101 porque un proxy delante de la aplicación quita las cabeceras Upgrade y Connection. La conexión entonces recurre a un plan alternativo o falla directamente.
• Pistas tempranas emitidas con enlaces a recursos que ya no existen, lo que desperdicia peticiones sin romper la página.

Cómo ver tú mismo una respuesta 1xx

1. Usa un cliente detallado. El curl -I normal solo muestra las cabeceras de la respuesta final, así que pide el intercambio completo en su lugar:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Un servidor que coopera responde HTTP/1.1 100 Continue antes de que salga el cuerpo, y luego el 2xx o 4xx final.
2. Para una ruta de WebSocket, comprueba que el saludo llega a HTTP/1.1 101 Switching Protocols. Si no lo hace, mira primero la capa del proxy: las cabeceras de actualización son de salto a salto, y varias configuraciones habituales de proxy inverso las descartan por defecto.
3. Para las pistas tempranas, pide la página y busca un bloque 103 antes de la respuesta final. No todos los intermediarios lo dejan pasar, así que un 103 ausente no siempre significa que el origen no esté enviando uno.
4. Si una subida grande se queda colgada sin ninguna respuesta en absoluto, reinténtalo sin la cabecera Expect. Si el reintento tiene éxito, algo entre tú y el origen se está tragando las respuestas provisionales.

Monitorizar un intercambio que no puedes ver

Como los códigos 1xx nunca llegan a un registro ni a un panel, lo que monitorizas es la respuesta final y cuánto tardó en llegar. Una ruta de subida bloqueada en una respuesta provisional se ve desde fuera exactamente igual que un endpoint lento o que agota el tiempo de espera, y una comprobación externa lo detecta de inmediato. HostTracker ejecuta comprobaciones desde más de 300 puntos de control en 158 ciudades, así que una petición que se cuelga detrás de una ruta de red concreta se puede distinguir de una caída genuina. Pasa una URL por la herramienta de comprobación HTTP para ver el estado final y el tiempo de respuesta. Las guías de los códigos de éxito 2xx y los códigos de redirección 3xx cubren las respuestas que sí terminan un intercambio.