- Software y sistemas
- Servicio HTTP
417
HTTP 417 Expectation Failed en servidor: fallo con Expect
Nivel de riesgo
Seguro
Puedes actuar sin peligro siguiendo las comprobaciones seguras.
Urgencia
Media — atiéndelo hoy
Respuesta rápida
El código HTTP 417 (Expectation Failed) indica que al menos uno de los servidores de entrada no pudo cumplir la expectativa enviada en la cabecera Expect de la petición. Revisa el valor de Expect; si tu cliente envió Expect: 100-continue y recibió 417, repite la solicitud sin esa cabecera.
Seguridad primero
Antes de continuar
- No dejes que un cliente que envía Expect: 100-continue espere indefinidamente la respuesta 100 Continue ni aborte sin reintentar al recibir 417: RFC 9110 sección 10.1.1 indica repetir la solicitud sin la expectativa 100-continue.
- No desactives la autenticación ni los límites de tamaño del servidor para evitar un HTTP 417: el propósito legítimo de Expect: 100-continue es precisamente evaluar las cabeceras (como autorización o permisos) antes de transferir un cuerpo pesado.
Puedes hacerlo con seguridad
- Inspeccionar el valor exacto del campo de cabecera Expect y si la petición incluye cuerpo
- Repetir la solicitud una sola vez sin la cabecera Expect: 100-continue tal como indica RFC 9110
- Identificar qué salto de entrada (proxy inverso, balanceador o servidor de origen) emite el 417
Deja estas tareas a un profesional cualificado
- No intentes esta tarea profesional: Configuración del cliente HTTP para reintentar sin Expect: 100-continue y no enviarlo sin cuerpo
- No intentes esta tarea profesional: Adecuación del servidor de origen o proxy al manejo estándar de Expect: 100-continue en HTTP/1.1+
Lo que un técnico debe poder justificar
Viene un técnico
Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.
No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.
Configuración del cliente HTTP para reintentar sin Expect: 100-continue y no enviarlo sin cuerpo
Qué haceEl equipo de desarrollo del cliente (p. ej., librerías HTTP como cURL, clientes .NET o SDKs de subida) debe configurar el cliente para que no genere Expect: 100-continue en peticiones sin contenido y para que repita automáticamente sin esa cabecera cuando reciba 417.
Te tiene que enseñarla traza HTTP del cliente enviando la petición sin la cabecera Expect (o reintentándola sin ella tras un 417) y obteniendo respuesta final del servidor.
Por escritoel ajuste de configuración aplicado en el cliente HTTP y las rutas o métodos afectados.
Adecuación del servidor de origen o proxy al manejo estándar de Expect: 100-continue en HTTP/1.1+
Qué haceCuando se requieren subidas grandes con validación previa de cabeceras, el equipo de plataforma o administración del servidor debe asegurar que el origen y los proxies cumplan el flujo de 100 (Continue) o respuesta final inmediata en conexiones HTTP/1.1 o superiores.
Te tiene que enseñarla captura en que el servidor devuelve 100 Continue (o el error final 401/405/413 correspondiente) en lugar de 417 ante Expect: 100-continue.
Por escritoel cambio de versión de protocolo en el upstream o la configuración actualizada del servidor/proxy.
Antes de aceptar una pieza o reparación
Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.
Sigue estos pasos
Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.
Inspeccionar el valor exacto del campo de cabecera Expect y si la petición incluye cuerpo
- Quién:
- Tú como desarrollador o integrador del cliente HTTP, revisando las cabeceras salientes de la petición.
- Cómo:
- Captura la solicitud que recibió el código 417 Expectation Failed y comprueba qué valor exacto lleva la cabecera Expect (recordando que es insensible a mayúsculas pero en RFC 9110 solo admite 100-continue sin parámetros) y si la petición transporta realmente contenido.
- Resultado que importa:
- Verificas si el cliente envió un valor inválido en Expect o añadió 100-continue a una petición sin cuerpo.
- Si la cabecera Expect contenía un valor personalizado, parámetros extra o se adjuntó a una petición sin contenido (como un GET o HEAD vacío), confirma que el error está en la generación de la solicitud del cliente.
- Si la petición sí enviaba contenido y la cabecera era exactamente Expect:
- 100-continue, descarta un error de sintaxis en Expect e indica probar el reenvío sin la cabecera Expect.
- Evidencia a conservar:
- Conserva las cabeceras de la solicitud (Expect, Content-Length o Transfer-Encoding) y la respuesta 417 recibida.
No manipules configuraciones de seguridad ni reenvíes cargas masivas en bucle sin verificar primero las cabeceras de la traza.
Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics
Repetir la solicitud una sola vez sin la cabecera Expect: 100-continue tal como indica RFC 9110
- Quién:
- Tú como persona desarrolladora de la aplicación cliente o responsable de pruebas de integración.
- Cómo:
- Sigue la regla de cliente de RFC 9110 sección 10.1.1: cuando una petición con Expect: 100-continue recibe un estado 417 (Expectation Failed), repite esa solicitud suprimiendo la cabecera Expect: 100-continue y enviando directamente el contenido.
- Resultado que importa:
- Compruebas si el servidor de destino procesa correctamente la solicitud cuando no se le exige el paso previo 100 Continue.
- Si al quitar Expect:
- 100-continue la petición se completa con éxito, confirma que algún servidor de la cadena no admite expectativas y que el cliente debe desactivar 100-continue para esa ruta.
- Si al repetir sin Expect aparece otro estado (como 401 Unauthorized, 405 Method Not Allowed o 413 Content Too Large), confirma que el servidor aplicó ahora la validación normal de la petición.
- Evidencia a conservar:
- Guarda el registro comparativo de la petición con Expect: 100-continue (417) y la petición sin Expect.
Realiza la prueba en entorno controlado o con una carga pequeña cuando el método modifique estado.
Evidencia: RFC 9110 - HTTP Semantics
Identificar qué salto de entrada (proxy inverso, balanceador o servidor de origen) emite el 417
- Quién:
- Tú como administrador de sistemas u operador de plataforma revisando los logs de cada capa HTTP.
- Cómo:
- Comprueba en los registros del proxy o pasarela y del servidor de origen cuál de los servidores de entrada generó el 417 y si existe algún tramo configurado en HTTP/1.0 hacia el backend.
- Resultado que importa:
- Localizas el servidor concreto de la cadena que rechaza la cabecera Expect.
- Si un intermediario corta el flujo con 417 antes del origen, confirma que el rechazo nace en ese salto intermedio (por ejemplo, un tramo HTTP/1.0).
- Si la solicitud llega al servidor de origen y este emite 417 ante un 100-continue válido con cuerpo, indica revisar la configuración de Expect en el origen.
- Evidencia a conservar:
- Anota la versión del protocolo HTTP empleada en cada tramo entre proxy y servidor de origen.
Evidencia: RFC 9110 - HTTP Semantics
Situación no resuelta
Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.
Dónde se aplica este código
Un código solo tiene significado dentro del producto y la versión correctos.
Ámbito principal
- Sistema
- Software y sistemas
- Marca
- HTTP
- Tipo de producto
- Servicio HTTP
Variantes conocidas del código
- 417 Aspettativa non soddisfatta
- 417 Échec de l’attente
- 417 Erwartung fehlgeschlagen
- 417 Expectation Failed
- 417 Expectativa fallida
- HTTP 417
- HTTP status 417
Qué significa
Definido en la sección 15.5.18 de RFC 9110 e inscrito en el registro IANA dentro de la clase 4xx (Client Error), el estado HTTP 417 (Expectation Failed) señala que la expectativa declarada por el cliente en el campo de cabecera de solicitud Expect (sección 10.1.1) no pudo ser satisfecha por al menos uno de los servidores de la cadena de entrada. La única expectativa definida en RFC 9110 es 100-continue (sin parámetros), que permite a un cliente que va a enviar contenido consultar antes si recibirá una respuesta provisional 100 (Continue); cualquier otro token en Expect puede rechazarse con 417. Por sí solo, 417 nunca demuestra un fallo de hardware ni qué eslabón rechazó la expectativa.
Advertencias y condiciones de parada
- Precauciónverificada con fuente
No dejes que un cliente que envía Expect: 100-continue espere indefinidamente la respuesta 100 Continue ni aborte sin reintentar al recibir 417: RFC 9110 sección 10.1.1 indica repetir la solicitud sin la expectativa 100-continue.
Evidencia: RFC 9110 - HTTP Semantics
- Seguroverificada con fuente
No desactives la autenticación ni los límites de tamaño del servidor para evitar un HTTP 417: el propósito legítimo de Expect: 100-continue es precisamente evaluar las cabeceras (como autorización o permisos) antes de transferir un cuerpo pesado.
Evidencia: RFC 9110 - HTTP Semantics
Síntomas y causas
Causas probables · en orden
- Cabecera Expect con un token o parámetro distinto de 100-continue no admitido por el servidorConfirmada
Según RFC 9110 sección 10.1.1, la única expectativa definida por el estándar es 100-continue (sin parámetros), y cualquier servidor que reciba en el campo Expect un miembro diferente a 100-continue puede responder con 417 Expectation Failed.
Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics
- Cadena de servidores o intermediario HTTP/1.0 que no soporta expectativas 100-continueFrecuente
De acuerdo con RFC 9110 secciones 10.1.1 y 15.5.18, un cliente que envía Expect: 100-continue recibe 417 cuando al menos uno de los servidores de entrada en la cadena no soporta expectativas (por ejemplo, cuando pasa a través de un servidor HTTP/1.0).
Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics
- Envío indebido de Expect: 100-continue en una solicitud que no incluye contenidoPosible
La sección 10.1.1 de RFC 9110 prohíbe expresamente al cliente generar una expectativa 100-continue en una petición que no incluya contenido (cuerpo de mensaje), lo que provoca rechazos en servidores o pasarelas que validan el encuadre.
Evidencia: RFC 9110 - HTTP Semantics
Técnico virtual
¿Sigue apareciendo 417 tras comprobarlo?
Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.
Fuentes y referencias técnicas
- 1
IANA HTTP Status Code Registry
Internet Assigned Numbers Authority · 2025 · standard
- 2
IETF / RFC Editor · 2022 · standard
¿Te ha resultado útil esta ficha?