Entrevista de backend: ¿Cómo usarías Expect: 100-continue para cargas de archivos grandes?

Planteamiento y alcance

Un cliente sube un archivo de varios cientos de megabytes al almacenamiento de objetos. El servidor puede rechazar un token inválido, una cuota o un tipo de medio usando solo los encabezados de la solicitud. Diseña el handshake de subida en HTTP/1.1 y explica Expect: 100-continue, el fallback con 417, saltos de proxy, tiempos de espera (timeouts), reintentos y métricas.

Esta es una pregunta de protocolo y confiabilidad de backend. El tamaño del archivo y los estados son suposiciones para el ejercicio, no afirmaciones de frecuencia.

Qué está evaluando el entrevistador

• Si separas la admisión basada únicamente en encabezados del procesamiento del cuerpo.
• Si describes con precisión 100, la respuesta final y 417.
• Si manejas expectativas ignoradas, tiempos de espera y reutilización de conexiones.
• Si los reintentos, la idempotencia, los checksums y la observabilidad tienen responsables claros.

Preguntas aclaratorias para hacer

1. ¿Es idempotente la subida y existe una sesión de subida o clave de idempotencia?
2. ¿Puede el cliente rebobinar la fuente del cuerpo y reabrir el archivo?
3. ¿Qué gateways y servicios de almacenamiento preservan las respuestas informativas?
4. ¿Se puede reintentar un intento fallido sin Expect, y podría esto crear un duplicado?
5. ¿Cuáles reglas son verificaciones exclusivas de encabezados y cuáles requieren leer el cuerpo completo?

Una respuesta de 30 segundos

“El cliente envía los encabezados con Expect: 100-continue. El servidor verifica la autenticación, la longitud, el tipo, la cuota y el enrutamiento; envía un 4xx final para un rechazo inmediato o 100 Continue cuando está listo para recibir el cuerpo. El cliente envía el cuerpo solo después de la respuesta provisional, con un tiempo de espera limitado. Una respuesta 417 puede desencadenar un reintento sin Expect solo cuando el cuerpo se puede rebobinar y es seguro repetir la operación. Mantengo la misma clave de idempotencia y mido el comportamiento del proxy, los bytes ahorrados, la tasa de 417 y los cuerpos abortados”.

Diseño paso a paso

1. Enviar primero los encabezados

La solicitud lleva autenticación, Content-Length, Content-Type, un digest, información del tenant, una clave de idempotencia y Expect: 100-continue. Antes de leer el cuerpo, el servidor puede verificar el token, la ruta, la cuota y el límite de tamaño estático. La especificación exige una respuesta después de la decisión; el cliente no debe esperar indefinidamente.

PUT /objects/o-123 HTTP/1.1
Host: upload.example
Authorization: Bearer ...
Content-Length: 524288000
Content-Type: application/octet-stream
Idempotency-Key: up-7f2
Expect: 100-continue

2. Manejar la admisión y el rechazo

Para la admisión, retorna 100 Continue, luego recibe el cuerpo. Si la autenticación es inválida, la longitud es excesiva o la cuota es insuficiente, retorna un estado final como 401, 403, 413 o 415; el cliente no debe enviar los bytes del cuerpo que aún no haya enviado. La verificación preliminar cubre solo las reglas visibles en los encabezados, por lo que el resultado final aún depende de la validación del cuerpo.

3. Usar 417 de manera estricta

417 Expectation Failed significa que el servidor o intermediario no puede cumplir con la expectativa. Si la operación lo permite, el cliente puede eliminar Expect y reenviar, pero debe ser capaz de rebobinar el cuerpo, preservar la clave de idempotencia y asegurarse de que la conexión anterior no tenga un cuerpo sin leer. No trates cada 4xx como 417 ni repitas tareas no idempotentes irreversibles.

4. Considerar esperas, proxies y conexiones

El cliente establece un límite de tiempo finito para la espera de 100 y registra la ruta del timeout. Los intermediarios HTTP/1.0 pueden ignorar Expect, y un proxy puede generar el 100 por sí mismo. Prueba cada salto para el reenvío de encabezados, el manejo de respuestas informativas y si un rechazo final cierra o drena la conexión; de lo contrario, los bytes sobrantes pueden corromper la reutilización de la conexión.

5. Hacer que los reintentos sean idempotentes

Reintenta solo cuando la fuente del cuerpo sea rebobinable y la operación de negocio permita la repetición. La creación de objetos o la deducción de cuota deben usar una clave de idempotencia estable para que los intentos se asignen a un solo resultado. Después de una desconexión, el resultado puede ser desconocido; consulta la sesión de subida o el estado del objeto antes de crear otro objeto.

6. Validar en ambas fases

Las comprobaciones previas cubren la autenticación, el tenant, la longitud, el tipo y la cuota. Después de recibir el cuerpo, valida el conteo real de bytes, el digest, el contenido malicioso y la política de almacenamiento. No confíes únicamente en Content-Length o en un tipo MIME declarado por el cliente. Registra el ID de solicitud, el resultado de la admisión y los bytes recibidos, nunca tokens ni el contenido del archivo.

Respuesta modelo de alta calidad

“Divido la subida en una decisión de encabezados y la ingesta del cuerpo. El cliente envía autenticación, longitud, tipo, digest, una clave de idempotencia y Expect: 100-continue. El servidor rechaza fallos económicos y deterministas antes del cuerpo; tras la admisión envía 100 y el cliente sube los datos. Un 417 provoca un reintento sin Expect solo cuando la repetición es segura, con la misma clave de idempotencia. Los tiempos de espera agotados, las desconexiones y el comportamiento del proxy se recuperan mediante consultas de estado. El tamaño del cuerpo, el digest y la seguridad del contenido se siguen validando. Pruebo la latencia de 100, 417, 4xx tempranos, la reutilización de conexiones y los bytes ahorrados a través de proxies reales”.

Errores comunes

• Tratar 100 como éxito → solo permite el cuerpo → espera el 2xx final o el fallo.
• Reintentar sin Expect tras cualquier 4xx → los efectos secundarios pueden duplicarse → fallback solo para 417 y repetición segura.
• Esperar indefinidamente por 100 → las solicitudes se cuelgan → limita y monitorea la espera.
• Verificar solo los encabezados → cuerpos corruptos o maliciosos entran al almacenamiento → valida también después de la ingesta.
• Ignorar las diferencias entre proxies → cuerpos tempranos o bytes sobrantes rompen la reutilización → prueba cada salto y controla la reutilización de conexiones.

Preguntas de seguimiento y respuestas

¿Qué pasa si el cliente envió bytes del cuerpo antes de recibir un 401?

El servidor sigue su política de conexión para cerrar o continuar leyendo y descartar el cuerpo. El cliente deja de enviar y marca el intento como fallido. La reutilización requiere demostrar que el estado del protocolo está alineado nuevamente.

¿Por qué no enviar siempre el cuerpo de inmediato?

Es posible que las solicitudes pequeñas no justifiquen el handshake. Las solicitudes grandes se benefician cuando los fallos de autenticación, longitud o cuota se pueden detectar temprano. Despliega según el tamaño de la solicitud, la compatibilidad del proxy y el costo de implementación.

¿Sigue teniendo importancia esta idea en HTTP/2 o HTTP/3?

No asumas un comportamiento idéntico a nivel de bytes. Verifica cómo el cliente, gateway y servidor elegidos manejan las respuestas informativas, el control de flujo y la cancelación de streams. Los objetivos duraderos siguen siendo el rechazo temprano, el estado de subida recuperable y la idempotencia.