Códigos de estado HTTP

Nombre: Camila Saavedra

Institución: Duoc UC

Curso: Lenguaje de Programación

Sigla: LPD 3111-001D

Profesor: Luis Felipe Ramirez Varela

Fecha: 02 de Junio de 2026

Resumen

En este informe hablaremos sobre los códigos de respuestas HTTP y sus cinco clases de respuesta: respuestas informativas, peticiones correctas, redirecciones, errores del cliente y errores del servidor.

Índice

Introducción

El protocolo HTTP (HyperText Transfer Protocol) es el fundamento de la comunicación de datos en la World Wide Web. Cada vez que un navegador realiza una solicitud a un servidor web, este responde con un código de estado numérico de tres dígitos que informa al cliente el resultado de la operación: si fue exitosa, si se requiere alguna acción adicional, si hubo un error y en qué extremo de la comunicación se originó.

Estos códigos se agrupan en cinco clases según su primer dígito. Los 1xx corresponden a respuestas provisionales o informativas; los 2xx confirman que la petición fuerecibida, comprendida y procesada con éxito; los 3xx indican que el cliente debe realizar una acción adicional, usualmente seguir una redirección; los 4xx señalan errores originados en el lado del cliente; y los 5xx indican un fallo interno del servidor.

Los códigos de estado están definidos de forma oficial en el RFC 9110 - HTTP Semantics, publicadas por el IETF en junio de 2022, disponible en https://www.rfc-editor-org/rfc/rfc9110; y el registro completo es mantenido por la IANA en https://www.iana.org/assignments/http-status-codes. La documentación de referencia más consultada por desarrolladores se encuentra en MDN Web Docs (https://developer.mozilla.org/es/docs/Web/HTTP/Status). Conocer estas fuentes y sus contenidos es fundamental para cualquier profesional del desarrollo web.

1.Respuestas informativas (1xx)

Con base al articulo publicado por MDN Web Docs (2026) en el sitio web de Mozilla podemos saber que "Los códigos de estado de respuesta HTTP indican si una solicitud HTTP especifíca se ha completado correctamente. Las respuestas se agrupan en cinco clases: respuestas informativas (1xx), respuestas satisfactorias (2xx), redirecciones (3xx), errores de los clientes y errores de los servidores (5xx)." Los códigos de la clase 1xx son respuestas provisionales o informativas que el servidor envía mientras procesa la petición. Indican que la solicitud fue recibida y el proceso continúa; el cliente debe esperar una respuesta final. Nunca incluyen cuerpo de respuesta. Según el registro de la IANA, la clase 1xx representa: "Informational-Request received, continuing process".

El código 100 Continue indica que el servidor recibió los encabezados y el cliente puede proceder a enviar el cuerpo de la petición; evita transmitir datos que el servidor podria rechazar. El código 101 Switching Protocols confirma que el servidor acepta cambiar el protocolo, como ocurre al establecer conexiones WebSocket. El código 102 Processing (WebDAV) evita que el cliente agote el tiempo de espera durante operaciones largas. El código 13 Early Hints, el más reciente, permite al servidor enviar encabezados de precarga antes de la respuesta final, mejorando el rendimiento al permitir al navegador comenzar a descargar recursos anticipadamente. En la práctica cotidiana, estos códigos son transparentes para el usuario final y operan a nivel de protocolo.

2.Peticiones correctas (2xx)

Los códigos de la clase 2xx indican que la petición fue recibida, comprendida y procesada exitosamente. Es la clase más deseable desde el punto de vista del cliente. Según la IANA, la clase 2xx representa: "Success-The action was successfully received, understood, and accepted". Dentro de esta clase existen matices importantes según la naturaleza de la operación.

El código más frecuente es el 200 OK que indica que la solicitud se realizó correctamente. El significado de "correcto" depende del método HTTP: GET-El recurso se ha obtenido y transmitido en el cuerpo del mensaje. POST-El recurso que describe el resultado de la acción se transmite en el cueerpo del mensaje ("200 OK", Developer Mozilla ORG, 2026). El código 201 Created se usa cuando una solicitud POST o PUT crea un nuevo recurso; el encabezado Loxation suele indicar la URL del recurso creado. El código 202 Accepted confirma que la petición fue aceptada pero su procesamiento continuará de forma asíncrona, común en colas de tareas. El código 2004 No Content confirma el éxito de la operación sin devolver cuerpo, habitual tras un DELETE exitoso. El código 206 Partial Content se usa cuando el servidor entrega solo la porción solicitada mediante el encabezado Range, fundamental para reanudar descargas y para el streaming de medios digitales.

3.Redirecciones (3xx)

Los códigos de la clase 3xx indican que el cliente debe realizar una acción adicional para completar la petición, generalmente seguir una redirección hacia otra URL. Son fundamentales para la getión del ciclo de vida de los recursos web, el posicionamiento SEO y el mantenimiento de aplicaciones. Según la IANA: "Redirection-Further action must be taken in order to complete the request".

El código 301 Moved Permanently: La URL del recurso solicitado ha cambiado permanentemente. La nueva URL se proporciona en la respuesta ("301 Moved Permanently", Developer Mozilla ORG, 2026). El código 302 Found señala un desplazamiento temporal; el cliente debe seguir usando la URL original en futuras peticiones. El código 303 See Other indica que la respuesta está en otra URL accesible solo mediante GET, muy usado tras envíos de formularios POST para evitar reenvíos duplicados. El código 304 Not Modified confirma que la copia en caché del cliente sigue siendo válida y ahorra ancho de banda al no enviar el cuerpo. Los códigos 307 Temporary Redirect y 308 Permanent Redirect son las variante modernas de 302 y 301 respectivamente, que garantizan que el método HTTP no cambia al realizar la redirección.

4.Errores del cliente (4xx)

Los códigos de la clase 4xx indican que la petición contiene un error atribuible al cliente: sintaxis incorrecta, falta de autenticación, permisos insuficientes o solicitud de un recurso inexistente. Según la IANA: "Client Error-The request contains bad syntax or cannot be fulfilled". A diferencia de los errores 5xx, el servidor funciona correctamente; fue la solicitud del cliente la que presentó el problema.

El código Bad Request se devuelve cuando la petición tiene sintaxis inválida o parámetros incorrectos. El código 401 Unauthorized indica que se requiere autenticación; aunque el nombre dice "no autorizado", semánticamente significa "no autenticado" . El código 403 Forbidden indica que el cliente está identificado pero no tiene permiso; reautenticarse no ayudará. 404 Not Found: El servidor no puede encontrar el recurso solicitado. En el navegador, esto significa que la URL no se reconoce. En una API, también puede significar que el punto final es válido, pero el recurso en sí no exite.("404 Not Found", Developer Mozilla ORG, 2026). El código 405 Method Not Allowed indica que el método HTTP usado no está permitido para ese recurso. El código 422 Unprocessable Content es muy utilizado en APIs REST cuando el JSON está bien formado pero contiene datos semánticamente inválidos. El código 429 Too Many Requests implementa control de tasa (rate limiting). El código 451 Unavailable For Legal Reasons se usa cuando el contenido no puede servirse por razones legales; su número homenajea la novela Fahrenheit 451 de Ray Bradbury.

5.Errores del servidor (5xx)

Los códigos de la clase 5xx indican que el servidor falló al intentar procesar una perición que parece ser válida. El error no está en la solicitud del cliente sino en el funcionamiento interno del servidor o en su comunicación con otros servicios. Según la IANA:"Server Error-The server failed to fulfill an apparently valid request".

El código 500 Internal Server Error es el error genérico de servidor: indica un fallo inesperado en el código o la configuración. El código 501 Not Implemented se devuelve cuando el servidor no reconoce o no soporta el método HTTP utilizado. El código 502 Bad Gateway indica que un servidor actuando como proxy recibió una respuesta inválida del servidor de origen; es muy común en configuraciones con nginx o balanceadores de carga. 503 Service Unavailable: El servidor no está listo para procesar la solicitud. Las causas comunes son que el servidor esté fuera de servicio por mantenimiento o sobrecargado. Tenga en cuenta que, junto con esta respuesta, deberia enviarse una página fácil de usar que explique el problema.("503 Service Unavailable", Developer Mozilla ORG, 2026). El código 504 Gateway Timeout, similar al 502, indica que el proxy no recibió respuesta a tiempo del servidor de origen. El código 511 Network Authentication Required lo usan portales cautivos (hoteles, aeropuertos) para exigir autenticació en la red antes de dar acceso a Internet.

Conclusión

A lo largo de este informe se han analizado las cinco clases de códigos de respuestas HTTP y los código más representativos de cada una. Los 1xx son respuestas provisionales que operan de forma transparente para el usuario. Los 2xx confirman el éxito con matices importantes: 200 para éxito genérico, 201 cuando se crea un recurso, 204 cuando no hay contenido que retornar y 206 para contenido parcial. Los 3xx gestionan la movilidad de recursos y son críticos para el SEO, con diferencias clave entre redirecciones permanentes (301, 308) y temporales (302, 307). Los 4xx señalan errores del cliente, donde la distinción entre 401(no autenticado) y 403(no autorizado) es especialmente relevante en el diseño de APIs. Los 5xx señalan fallos del servidor siendo 502 y 504 los más comunes en arquitecturas con proxies y balanceadores de carga.

Todos estos códigos están definidos oficialmente en el RFC 9110 del IETF, resgistrados por la IANA y documentados de forma accesible en MDN Web Docs. Como futuros profesionales del área digital, dominar estos códigos y sus fuentes oficiales nos permite diseñar aplicaciones más robustas y diagnostica problemas con mayor precisión y criterio técnico.