Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

206

HTTP 206 Partial Content: respuesta correcta con una parte

Verificada con fuentes2 fuentesRevisada 4 oct 2026
¿Viene un técnico? Mira los 2 pasos que debe enseñarte

Nivel de riesgo

Seguro

Puedes actuar sin peligro siguiendo las comprobaciones seguras.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

HTTP 206 significa que el servidor entrega solo la parte del recurso que pidió el cliente con una cabecera Range: es un éxito, útil para reanudar descargas o leer trozos de archivos grandes. Si la descarga queda incompleta, revisa que el cliente pida el resto.

Seguridad primero

Antes de continuar

  • En monitores y estadísticas, cuenta el 206 como respuesta correcta: IANA lo registra en la clase 2xx de éxito y tratarlo como fallo genera falsas alarmas.

Puedes hacerlo con seguridad

  • Resultado final de la descarga o reproducción
  • Range pedido frente a Content-Range recibido
  • Método usado para pedir el rango

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Lectura de Content-Range en el cliente
  • No intentes esta tarea profesional: Revisión del soporte de rangos en servidor y CDN

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.

  1. Lectura de Content-Range en el cliente

    Qué haceEl desarrollador hace que el cliente revise Content-Type y Content-Range de cada 206 y pida las partes que faltan.

    Te tiene que enseñaruna descarga grande completada a partir de varias respuestas 206.

    Por escritoel cambio y la versión del cliente que lo incluye.

  2. Revisión del soporte de rangos en servidor y CDN

    Qué haceEl administrador comprueba que el servidor de origen y la caché intermedia devuelven rangos coherentes con lo pedido.

    Te tiene que enseñaruna petición con Range a través de la CDN y su respuesta.

    Por escritola configuración revisada y el resultado.

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.

  1. Resultado final de la descarga o reproducción

    Sin herramientas especiales

    Quién:
    tú, en la aplicación o el navegador.
    Cómo:
    deja que termine la descarga o el vídeo y compara el tamaño final con el que anuncia el sitio.
    Resultado que importa:
    si el archivo llega completo.
    Si llega completo:
    confirma que los 206 eran partes de una transferencia correcta.
    Si queda incompleto:
    indica que el cliente no pidió o no unió todas las partes; pásalo al desarrollador.
    Evidencia a conservar:
    tamaño final obtenido y tamaño anunciado.

    Evidencia: RFC 9110 - HTTP Semantics

  2. Range pedido frente a Content-Range recibido

    Sin herramientas especiales

    Quién:
    el desarrollador, con las herramientas de red o un cliente HTTP.
    Cómo:
    compara el rango de Range con el que devuelve Content-Range, el Content-Length de la parte y la longitud total indicada.
    Resultado que importa:
    si el servidor entregó todo lo pedido.
    Si entregó menos:
    confirma un envío parcial del servidor; el cliente debe pedir el resto.
    Si coincide:
    descarta el servidor y revisa cómo el cliente encadena las partes.
    Evidencia a conservar:
    pares de petición y respuesta guardados.

    Evidencia: RFC 9110 - HTTP Semantics

  3. Método usado para pedir el rango

    Sin herramientas especiales

    Quién:
    el desarrollador.
    Cómo:
    comprueba que el rango se pide con GET, el único método con manejo de rangos definido en RFC 9110.
    Resultado que importa:
    el método de la petición.
    Si es otro método:
    indica que el servidor debe ignorar Range; cambia la petición a GET.
    Si es GET:
    descarta esta causa.
    Evidencia a conservar:
    traza de la petición con método y cabeceras.

    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

  • 206 Contenido parcial
  • 206 Contenu partiel
  • 206 Contenuto parziale
  • 206 Partial Content
  • 206 Teilinhalt
  • código 206 Epson
  • EcoTank 206 LINE and EXT port
  • EcoTank 206 puertos LINE y EXT
  • El cable telefónico no está bien conectado a los puertos LINE y EXT. del producto
  • Epson 206
  • Epson error code 206
  • Epson ET-5800 206
  • Epson ET-5805 206
  • Epson L6550 206
  • HTTP 206
  • HTTP status 206
  • The phone cable is incorrectly connected to the LINE and EXT. port of the product

Qué significa

RFC 9110 define 206 (Partial Content): el servidor atiende con éxito una petición de rango transfiriendo una o varias partes de la representación seleccionada. Puede enviar menos de lo pedido por motivos propios, como carga o eficiencia de caché, y la respuesta se describe a sí misma: el cliente debe revisar Content-Type y Content-Range para saber qué partes llegan y si necesita más peticiones. Solo GET tiene definido el manejo de rangos. El 206 no es un error del servidor.

Advertencias y condiciones de parada

  • Seguroadvertencia editorial

    En monitores y estadísticas, cuenta el 206 como respuesta correcta: IANA lo registra en la clase 2xx de éxito y tratarlo como fallo genera falsas alarmas.

    Evidencia: IANA HTTP Status Code Registry

Síntomas y causas

Causas probables · en orden

  • Petición de rango atendidaFrecuente

    El cliente pidió un rango con Range y el servidor lo entregó. Es el uso previsto y no requiere arreglo.

    Evidencia: RFC 9110 - HTTP Semantics

  • Servidor que entrega menos de lo pedidoPosible

    RFC 9110 admite enviar solo una parte por carga o caché; encaja si el cliente recibe menos bytes de los solicitados y tiene que pedir el resto.

    Evidencia: RFC 9110 - HTTP Semantics

  • Cliente que no completa las partesPosible

    Si la descarga se queda a medias, el cliente puede no estar leyendo Content-Range ni pidiendo lo que falta; se distingue porque el servidor sí responde a cada rango.

    Evidencia: RFC 9110 - HTTP Semantics

Técnico virtual

¿Sigue apareciendo 206 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. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Fuentes: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsrevisado 2026-10-04 · verificado

¿Te ha resultado útil esta ficha?