100

El código de respuesta 100 Continue en el protocolo HTTP es un código de estado informativo. Indica que el servidor ha recibido los encabezados iniciales de la solicitud del cliente y que el cliente puede continuar enviando el cuerpo de la solicitud (por ejemplo, el contenido de un archivo grande que se está cargando).

Este código se usa principalmente en situaciones donde el cliente envía una solicitud con cuerpo (como una solicitud POST o PUT) y utiliza el encabezado Expect: 100-continue. Este encabezado indica que el cliente desea verificar si el servidor está dispuesto a procesar la solicitud antes de enviar el cuerpo completo. Si el servidor responde con 100 Continue, el cliente envía el cuerpo de la solicitud.

Características Principales

Propósito: Optimizar el flujo de datos entre cliente y servidor, evitando enviar cuerpos grandes si el servidor no puede manejar la solicitud.

Cuando se usa: Se usa típicamente en solicitudes que incluyen el encabezado Expect: 100-continue.

Flujo de comunicación: El cliente envía una solicitud inicial con encabezados y el encabezado Expect: 100-continue. El servidor responde con 100 Continue si todo está en orden. El cliente envía el cuerpo de la solicitud. El servidor responde con un código final (como 200 OK o 400 Bad Request).

101

El código de respuesta 101 Switching Protocols en el protocolo HTTP es un código de estado que indica que el servidor acepta cambiar el protocolo de comunicación a uno solicitado por el cliente. Se utiliza principalmente para actualizar la conexión a un protocolo diferente, como en el caso del WebSocket.

Características Principales

Propósito: Notificar al cliente que el servidor ha aceptado cambiar el protocolo a uno diferente especificado en el encabezado Upgrade de la solicitud.

Casos de Uso Común: Actualización de HTTP/1.1 a WebSocket. Cambios a otros protocolos como HTTP/2 o HTTP/3.

Requisitos: El cliente incluye un encabezado Upgrade especificando el protocolo al que desea cambiar. El servidor responde con un encabezado Upgrade confirmando el cambio.

102

El código de respuesta 102 Processing es parte del protocolo HTTP/1.1 y está definido en la especificación RFC 2518, que introduce extensiones para el protocolo HTTP en el contexto de Web Distributed Authoring and Versioning (WebDAV).

Propósito del Código 102 Processing

Este código de estado indica que el servidor ha recibido y está procesando la solicitud, pero necesita más tiempo para completarla.

Usos Comunes

WebDAV: Se utiliza en operaciones complejas de WebDAV, como cuando se ejecutan múltiples operaciones en recursos (por ejemplo, copiar o mover un árbol de directorios). Evitar Timeouts: Responde al cliente que el servidor aún está trabajando en la solicitud, para evitar que el cliente asuma que la conexión se ha perdido.

Características Principales

Indicación de Progreso: Sirve como una señal al cliente de que la solicitud no ha sido olvidada. No Finaliza la Solicitud: La respuesta 102 Processing no es una respuesta final. La operación sigue en curso. Uso Limitado: Normalmente utilizado en contextos específicos (como WebDAV) y no en solicitudes HTTP estándar.

103

El código de estado 103 Early Hints en el protocolo HTTP es una respuesta provisional que permite a los servidores sugerir recursos vinculados antes de enviar la respuesta final. Esto ayuda a mejorar el rendimiento al permitir que los navegadores comiencen a precargar recursos importantes (como archivos CSS, JavaScript o imágenes) antes de que se reciba la respuesta completa.

Propósito

Reduce el tiempo de carga de la página web. Permite a los clientes obtener una "pista temprana" sobre recursos críticos que probablemente necesitarán para procesar la solicitud completa.

Usos Comunes

Se utiliza principalmente con encabezados como Link para indicar los recursos que el navegador puede cargar anticipadamente. Común en aplicaciones que implementan HTTP/2 o HTTP/3, ya que estas versiones del protocolo soportan bien la multiplexación.

Flujo de Trabajo

El servidor responde inicialmente con un código 103 Early Hints, incluyendo encabezados que apuntan a recursos necesarios. Luego, el servidor envía la respuesta completa con el estado final, como 200 OK.

Ventajas

Rendimiento: Reduce la latencia percibida al permitir que los navegadores predescarguen recursos importantes. Optimización: Ideal para aplicaciones web de alta carga que manejan muchos recursos críticos.

Soporte y Consideraciones

Algunos navegadores modernos ya soportan el código 103, pero su adopción aún no es universal. Debe usarse junto con protocolos que admitan conexiones rápidas y paralelas, como HTTP/2.

El código 103 Early Hints es una herramienta poderosa para optimizar tiempos de carga y mejorar la experiencia del usuario en la web.

200

El código HTTP 200 OK indica que la solicitud del cliente se procesó correctamente en el servidor y que la respuesta contiene el resultado esperado. Este código se utiliza en la mayoría de las respuestas exitosas, como en solicitudes GET o POST.

En una solicitud GET, un código 200 OK significa que el recurso solicitado fue encontrado y se devuelve en el cuerpo de la respuesta.

En una solicitud POST, significa que la operación se completó correctamente y se proporciona una respuesta con el estado o los datos resultantes.

Características Principales

Estándar en respuestas exitosas

El código 200 se utiliza para indicar que todo está bien y que el servidor pudo procesar la solicitud.

Contenido del cuerpo

Dependiendo de la operación, el cuerpo de la respuesta puede contener datos (como en GET) o un mensaje de confirmación (como en POST).

No siempre es necesario un cuerpo de respuesta

Aunque es común incluir información en el cuerpo, no siempre es obligatorio. Por ejemplo, en una solicitud DELETE exitosa, el cuerpo podría estar vacío.

Consistencia

El uso del código 200 ayuda a los clientes a comprender rápidamente que la operación fue exitosa sin necesidad de analizar en detalle el cuerpo de la respuesta.

201

El código de estado 201 Created indica que una solicitud HTTP ha sido procesada con éxito y ha resultado en la creación de un nuevo recurso. La ubicación del recurso recién creado generalmente se proporciona en el encabezado Location de la respuesta.

Características Principales

Método Usual

Generalmente asociado con solicitudes POST o PUT.

Encabezado Location

Especifica la URL del recurso recién creado.

Cuerpo de la Respuesta

Puede incluir una representación del recurso creado, aunque no es obligatorio.

Usos Comunes

Creación de Recursos Únicos: Un recurso único se genera como resultado de una solicitud, como un nuevo registro de usuario, la creación de un producto, o una entrada en un blog. Ejemplo: Registrar un nuevo cliente en una base de datos.

Indicación de la Ubicación del Recurso: Es útil cuando el cliente necesita saber la URL del recurso creado para realizar operaciones posteriores (como leer, actualizar o eliminar). Ejemplo: Crear una nueva orden en un sistema de compras y devolver la URL de esa orden.

Representación del Recurso en la Respuesta: Se puede incluir información adicional sobre el recurso recién creado para que el cliente no tenga que hacer otra solicitud para obtener los detalles. Ejemplo: Crear un archivo en un servicio de almacenamiento en la nube y devolver los metadatos del archivo.

Ventajas

Mejora la claridad de las respuestas HTTP al cliente. Simplifica la interacción con APIs RESTful al proporcionar directamente la ubicación del recurso creado. Fomenta el cumplimiento de los estándares HTTP, lo que ayuda en la interoperabilidad entre sistemas.

202

El código de estado 202 Accepted indica que el servidor ha recibido y aceptado la solicitud para ser procesada, pero el procesamiento aún no se ha completado. Este código no garantiza que el procesamiento de la solicitud vaya a finalizar con éxito; solo informa que se ha aceptado para su ejecución en el futuro.

Características Clave

Procesamiento Asíncrono: Utilizado comúnmente cuando la solicitud requiere un procesamiento que no puede completarse inmediatamente. Respuesta Informativa: Generalmente, no incluye el resultado final del procesamiento, sino una confirmación de aceptación. Métodos Usuales: Se puede asociar con POST, PUT, o incluso DELETE, dependiendo del contexto.

Usos Comunes

Procesamiento Largo o Diferido: Cuando la operación solicitada requiere tiempo significativo para completarse, como la generación de informes, análisis de datos, o procesamiento en lotes. Ejemplo: Enviar un archivo para análisis antivirus o conversión de formato. Procesos Asíncronos: Cuando el servidor delega la tarea a otro sistema o cola de procesamiento, y el resultado final estará disponible más tarde. Ejemplo: Iniciar un despliegue en un sistema CI/CD o una tarea de impresión. Feedback al Cliente sin Bloqueo: Se usa para notificar al cliente que la solicitud ha sido aceptada y procesada, pero sin bloquearlo hasta que el resultado esté listo. Ejemplo: Un sistema de correo masivo que confirma la recepción de una solicitud de envío sin esperar a que todos los correos sean entregados.

Ventajas

Mejora la experiencia del usuario en aplicaciones con operaciones de larga duración, al proporcionar una respuesta rápida en lugar de hacer que el cliente espere. Permite diseñar APIs más escalables al delegar tareas complejas a sistemas secundarios o colas de trabajo. Proporciona una base clara para manejar procesos asíncronos, permitiendo al cliente saber que su solicitud está en curso.

Ambos códigos (201 Created y 202 Accepted) son útiles en APIs RESTful, pero se utilizan en contextos diferentes según el propósito de la solicitud y la naturaleza del procesamiento del recurso.

203

El código de estado 203 Non-Authoritative Information indica que la solicitud se ha procesado con éxito, pero la respuesta no contiene información del servidor de origen. En cambio, la información de la respuesta puede haber sido modificada por un servidor intermedio, como un proxy o una caché. Este código se utiliza principalmente en escenarios donde el servidor intermedio devuelve datos que no provienen directamente de la fuente original o han sido transformados.

Características Principales

No Original: La información devuelta puede no coincidir con la del servidor de origen. Uso Raro: Su uso en APIs modernas es inusual, pero puede ser relevante en configuraciones específicas. Método Usual: Frecuentemente asociado con solicitudes GET.

Usos Comunes

Intervención de un Proxy o Intermediario: Se utiliza cuando un servidor intermedio modifica los datos antes de enviarlos al cliente. Ejemplo: Un proxy que traduce datos de un idioma a otro. Cachés Modificadas: Cuando un servidor caché devuelve una respuesta ajustada en lugar de la respuesta original del servidor. Ejemplo: Una CDN que transforma imágenes o ajusta contenido para adaptarse al dispositivo del cliente. Transformación de Datos: Cuando se aplican transformaciones, como normalización de datos o ajustes de formato, antes de enviar la respuesta. Ejemplo: Un servidor que estandariza las unidades de medida (p. ej., convierte de metros a pies).

Ventajas

Proporciona claridad al cliente sobre la fuente y precisión de los datos. Ayuda en sistemas distribuidos a diferenciar entre datos originales y transformados. Facilita el manejo de respuestas ajustadas o procesadas por intermediarios, sin atribuirlas directamente al servidor de origen.

Aunque su uso es raro, el código 203 tiene aplicaciones específicas en sistemas con servidores intermediarios que manipulan o transforman datos. En la mayoría de los casos, los códigos como 200 OK o 304 Not Modified son suficientes para representar el estado de una respuesta.

204

El código de estado 204 No Content indica que el servidor ha procesado con éxito la solicitud, pero no necesita devolver un cuerpo de respuesta. Se usa cuando no hay contenido que proporcionar al cliente, pero se confirma que la operación solicitada se completó correctamente.

Características Principales

Sin Contenido en el Cuerpo: La respuesta incluye solo los encabezados HTTP. Mantiene el Estado del Cliente: Ideal cuando el cliente no necesita recargar su interfaz o cambiar su estado como resultado de la respuesta. Métodos Usuales: Frecuentemente usado con DELETE, PUT, o acciones que actualizan datos sin necesidad de retroalimentación al cliente.

Usos Comunes

Confirmación Sin Contenido: Se necesita confirmar que la acción fue exitosa sin enviar datos adicionales. Ejemplo: Confirmar que se eliminó un recurso con éxito tras un DELETE. Optimización de Respuestas: Reducir la cantidad de datos transferidos al cliente cuando no es necesario enviar contenido. Ejemplo: Al guardar automáticamente un borrador sin cambiar la interfaz del cliente. Mantener la Experiencia del Usuario: Permitir que el cliente permanezca en la misma página o estado sin realizar actualizaciones visibles. Ejemplo: Una solicitud AJAX que actualiza un estado en el backend sin modificar la UI.

Ventajas

Reduce el tráfico de red al evitar enviar contenido innecesario. Mejora la experiencia del usuario al no recargar la interfaz sin necesidad. Proporciona una manera clara y eficiente de indicar éxito sin información adicional.

El código 204 es una excelente opción para operaciones rápidas y silenciosas que confirman el éxito de una acción sin sobrecargar la comunicación entre cliente y servidor. Su uso puede mejorar la eficiencia de las APIs y la experiencia de los usuarios en aplicaciones modernas.

205

El código de estado 205 Reset Content indica que el servidor ha procesado con éxito la solicitud, pero además solicita al cliente que reinicie o actualice su estado, como limpiar formularios o restablecer vistas en la interfaz de usuario. A diferencia del código 204, que no exige ninguna acción del cliente, el 205 indica explícitamente que el cliente debe realizar un reinicio.

Características Principales

Sin Cuerpo de Respuesta: Similar al código 204, no incluye contenido en el cuerpo. Acción Requerida por el Cliente: Se utiliza cuando el cliente debe realizar un restablecimiento visual o funcional. Métodos Usuales: A menudo asociado con solicitudes como POST, PUT o DELETE.

Usos Comunes

Reinicio de Formularios o Interfaces: Después de que se envíe un formulario, el servidor puede solicitar que el cliente lo limpie. Ejemplo: Un formulario de registro que debe restablecerse tras enviarse con éxito. Restablecimiento de Estado Visual: Cuando el servidor desea que el cliente elimine datos visualizados temporalmente. Ejemplo: Restablecer una vista de filtro o búsqueda después de aplicar cambios. Preparación para Nuevas Interacciones: Ideal para aplicaciones interactivas donde el cliente debe estar listo para la siguiente acción. Ejemplo: Un sistema de encuestas que debe reiniciar la vista tras enviar una respuesta.

Ventajas

Proporciona una manera estandarizada de instruir al cliente para que actualice su estado. Mejora la experiencia del usuario al limpiar automáticamente vistas o formularios sin necesidad de intervención manual. Reduce la complejidad del cliente al delegar la responsabilidad del reinicio al servidor.

Diferencias con 204 No Content

204 No Content: Indica éxito sin contenido adicional, pero no requiere ninguna acción del cliente. 205 Reset Content: Indica éxito y además solicita explícitamente al cliente que reinicie o actualice su estado.

El uso de 205 Reset Content es ideal para aplicaciones donde el cliente necesita orientación clara para restablecer su interfaz o estado después de una operación exitosa.

206

El código de estado 206 Partial Content indica que el servidor ha procesado exitosamente una solicitud parcial de un recurso. Esto sucede cuando el cliente utiliza el encabezado Range para pedir una parte específica del recurso, como una sección de un archivo grande.

Características Principales

Respuestas Parciales: Se envía solo la parte solicitada del recurso, no el contenido completo. Encabezado Content-Range: El servidor incluye este encabezado en la respuesta para indicar el rango del recurso que se está devolviendo. Optimización de Recursos: Es útil para descargar archivos grandes, transmitir videos, o retomar descargas interrumpidas.

Usos Comunes

Transmisión de Videos o Audios: Los reproductores multimedia solicitan rangos específicos de un archivo para transmitir solo las partes necesarias en un momento dado. Ejemplo: Un usuario que avanza rápidamente a la mitad de un video. Descargas Interrumpidas: Permite retomar descargas desde el punto donde se detuvieron, en lugar de reiniciarlas desde el principio. Ejemplo: Un gestor de descargas que solicita el resto de un archivo tras una desconexión. Optimización de Ancho de Banda: Reduce el tráfico de red enviando solo las partes necesarias de un recurso. Ejemplo: Una aplicación que carga imágenes o documentos en partes mientras el usuario las visualiza.

Ventajas

Content-Range: Especifica el rango del recurso devuelto (por ejemplo, bytes 0-1023/1048576). Content-Length: Indica el tamaño de la porción devuelta. Accept-Ranges: En una solicitud previa, el servidor puede indicar si soporta rangos con este encabezado (por ejemplo, bytes).

El código 206 Partial Content es esencial para servicios que manejan recursos grandes y buscan eficiencia y flexibilidad en la entrega de contenido al cliente.

207

Es una respuesta específica del protocolo que indica que la solicitud ha sido procesada y que el cuerpo de la respuesta contiene múltiples códigos de estado. Es útil cuando una operación afecta a varios recursos, y el servidor necesita proporcionar información detallada sobre el éxito o el error para cada uno de ellos. La respuesta se entrega en un formato XML que describe el resultado de cada operación.

Características Clave

Múltiples Resultados: Permite que el servidor informe sobre el éxito o error de varias operaciones en una sola respuesta. Formato XML: La respuesta incluye un documento XML con detalles de los recursos afectados y sus códigos de estado individuales. Usos Exclusivos de WebDAV: Generalmente se utiliza en aplicaciones que implementan el protocolo WebDAV para manejar operaciones en recursos como archivos o carpetas.

Usos comunes

Gestión de Archivos en Servidores: Operaciones como copiar, mover o eliminar varios archivos o carpetas. Ejemplo: Un cliente WebDAV que sincroniza un directorio completo con un servidor.

Sincronización de Recursos: Informar sobre cambios o conflictos en múltiples recursos durante la sincronización. Ejemplo: Una aplicación de respaldo en la nube que verifica el estado de múltiples archivos.

Operaciones en Lote: Permite ejecutar y obtener resultados para varias operaciones en una sola solicitud. Ejemplo: Actualización masiva de propiedades o metadatos de recursos en un servidor.

Ventajas

Eficiencia: Reduce el número de solicitudes necesarias para manejar múltiples recursos. Detalles Individuales: Permite al cliente conocer el estado de cada recurso afectado. Flexibilidad: Ideal para sistemas complejos que gestionan varios recursos simultáneamente.

El uso de 207 Multi-Status es crucial en aplicaciones avanzadas que gestionan múltiples recursos en servidores compatibles con WebDAV, mejorando la comunicación entre cliente y servidor.

208

Indica que los miembros de un recurso vinculado ya se han enumerado en una respuesta anterior, y no se repiten nuevamente en la respuesta actual para evitar redundancia. Este código se usa principalmente en respuestas a solicitudes PROPFIND con una profundidad mayor que 0, donde se enumeran múltiples recursos. Al devolver 208, el servidor informa que ciertos recursos ya se describieron previamente y no necesitan repetirse.

Características Clave

Evita Duplicados: Reduce el tamaño de las respuestas al no repetir información sobre recursos que ya se han informado.

Usos en WebDAV: Exclusivo para operaciones WebDAV como PROPFIND, donde se listan propiedades o recursos jerárquicos.

Optimización: Minimiza la sobrecarga de red al evitar datos redundantes.

Caso de Uso

Gestión de Árboles de Directorios: Cuando se enumeran recursos jerárquicos, evita la repetición de información sobre subdirectorios o archivos ya reportados.

Optimización en Consultas WebDAV: Reduce la cantidad de datos enviados en respuestas PROPFIND o similares, optimizando el uso de red y procesamiento.

Sincronización de Recursos: Facilita la sincronización de estructuras complejas de archivos o propiedades, indicando al cliente qué recursos ya se han procesado.

Ventajas

Eficiencia: Evita duplicar datos en respuestas, ahorrando ancho de banda y tiempo de procesamiento.

Claridad: Informa explícitamente que un recurso ya ha sido reportado en la misma transacción.

Reducción de Redundancia: Especialmente útil en estructuras jerárquicas o recursos enlazados.

El código 208 Already Reported mejora la eficiencia de las operaciones en sistemas que gestionan múltiples recursos jerárquicos, asegurando que los clientes solo reciban la información necesaria sin redundancias innecesarias.

226

El código de estado HTTP 226 IM Used se utiliza para indicar que el servidor ha cumplido con una solicitud GET para un recurso y que la respuesta se generó utilizando una o más manipulaciones de contenido (deltas). Esto permite enviar únicamente las diferencias entre una versión previa del recurso y la versión actual, en lugar de transferir todo el recurso completo. Este código es definido como parte del protocolo HTTP Delta Encoding. Es particularmente útil en situaciones donde un cliente ya posee una versión del recurso y solo necesita recibir actualizaciones incrementales.

Características Clave

Reducción del Tamaño de la Respuesta: Solo se envían los cambios entre dos versiones del recurso, lo que optimiza el uso del ancho de banda.

Cabecera IM: El servidor utiliza esta cabecera en la respuesta para indicar qué manipulaciones específicas se aplicaron.

Usos Avanzados: Común en sistemas donde se sincronizan datos frecuentemente, como aplicaciones de colaboración en tiempo real o sincronización de archivos.

Usos comunes

Sincronización de Datos: El código 226 IM Used es útil en escenarios donde un cliente mantiene una copia local de los datos y necesita sincronizar los cambios de manera eficiente

Aplicaciones de Colaboración: Herramientas como Google Docs o plataformas colaborativas donde múltiples usuarios editan el mismo documento.

Transferencia de Archivos: Sincronización incremental de datos en aplicaciones como Dropbox o sistemas de control de versiones.

APIs y Servicios Web: APIs que proporcionan datos actualizados sin necesidad de retransmitir toda la información.

Ventajas

Eficiencia: Reduce el tamaño de las respuestas HTTP, mejorando el rendimiento.

Ahorro de Ancho de Banda: Ideal para aplicaciones con recursos grandes o redes de baja velocidad.

Sincronización Rápida: Facilita mantener datos actualizados en tiempo real.

El código HTTP 226 IM Used es una herramienta poderosa para mejorar la eficiencia en la transferencia de datos, especialmente en sistemas que manejan versiones de recursos o sincronización incremental.

300

El código de estado HTTP 300 Multiple Choices indica que el recurso solicitado tiene múltiples representaciones posibles y el cliente debe elegir una. Esta respuesta se usa cuando hay varias opciones disponibles para un mismo recurso, y el servidor proporciona información sobre esas opciones para que el cliente seleccione la más adecuada. Este código generalmente se utiliza en situaciones donde un recurso tiene múltiples formatos, idiomas o versiones.

Características Clave

Múltiples Opciones Disponibles: El recurso solicitado tiene más de una representación posible.

Selección por Parte del Cliente: El cliente puede elegir cuál opción prefiere, ya sea manualmente o mediante cabeceras como Accept-Language o Accept.

Ubicación en la Respuesta: Se proporciona una lista de URLs alternativas en el cuerpo de la respuesta o en la cabecera Location.

No Obligatorio Redirigir: A diferencia de otros códigos de redirección (301, 302), el cliente no está obligado a seguir una URL específica.

Usos comunes

Sitios Multilingües: Un sitio web con contenido disponible en varios idiomas podría usar 300 Multiple Choices para sugerir diferentes versiones según la configuración del navegador del usuario.

Diferentes Formatos de Archivo: Cuando un archivo está disponible en múltiples formatos (JSON, XML, CSV), el cliente puede elegir la mejor opción.

Versiones de un API: Un API REST que admite varias versiones (v1, v2) puede devolver un 300 cuando un cliente no especifica la versión deseada.

Ventajas

Flexible: Permite a los clientes seleccionar la mejor representación del recurso.

Útil en Servicios REST: Facilita la entrega de contenido en múltiples formatos.

Poca Implementación en la Práctica: La mayoría de los servicios prefieren redirigir automáticamente (301, 302) en lugar de requerir interacción del cliente.

No Soportado por Algunos Navegadores: Algunos navegadores pueden no manejar adecuadamente el código 300 y simplemente mostrar una página en blanco.

El código 300 Multiple Choices es útil cuando un recurso tiene múltiples representaciones, pero su uso no es común en la web moderna debido a que los servidores suelen redirigir automáticamente a una opción predeterminada.

301

El código de estado 301 Moved Permanently indica que un recurso ha sido trasladado de forma permanente a una nueva URL. Cualquier solicitud futura debe dirigirse a esta nueva ubicación. Los navegadores y motores de búsqueda suelen actualizar automáticamente sus enlaces a la nueva URL.

Usos comunes

Migración de URL de una página a otra Si cambias la estructura de tu sitio web y deseas redirigir tráfico sin perder SEO. Ejemplo: https://miweb.com/blog/post-antiguo https://miweb.com/articulos/post-nuevo.

Cambio de dominio Si una empresa cambia de dominio y quiere redirigir todo el tráfico de https://antiguodominio.com a https://nuevodominio.com. Forzar HTTPS - Redirigir automáticamente tráfico HTTP a HTTPS: ```htaccess RewriteEngine on RewriteCond %HTTPS off RewriteRule ^.*$ https://%HTTP_HOST/$1 R=301,L ``` - Esto garantiza que todos los usuarios usen una conexión segura.

Eliminar www o agregarlo - Para evitar duplicidad en URLs `www` y sin `www`, redirigir siempre a una versión única. - Ejemplo en `.htaccess`: ```htaccess RewriteEngine on RewriteCond %HTTP_HOST ^www.ejemplo.com NC RewriteRule ^.*$ http://ejemplo.com/$1 L,R=301 ```

301 Moved Permanently significa que la URL ha cambiado para siempre. El navegador o cliente debe usar la nueva URL en futuras solicitudes. Se usa comúnmente para SEO, redirecciones de dominios y cambios de estructura en sitios web.

302

El código de estado 302 Found indica que el recurso solicitado se ha movido temporalmente a otra ubicación. A diferencia del código 301 Moved Permanently, esta redirección es temporal, por lo que los clientes navegadores, motores de búsqueda, etc. no deben actualizar sus enlaces y deben seguir solicitando la URL original en el futuro.

Usos comunes

Mantenimiento de páginas Si un sitio web está en mantenimiento y deseas redirigir temporalmente a otra página sin cambiar la URL definitiva. Ejemplo: https://miweb.com/inicio a https://miweb.com/mantenimiento.

Autenticación y acceso a contenidos** Cuando un usuario intenta acceder a una página privada sin estar autenticado y se lo redirige temporalmente a una página de inicio de sesión. Ejemplo en **Express.js**: ```js app.get'/dashboard', req, res = if !req.user res.redirect302, '/login' // Redirección temporal al login else res.send'Bienvenido al Dashboard' ```

Control de tráfico dinámico Un servicio web puede redirigir usuarios a diferentes servidores según la carga del sistema. Ejemplo: https://api.ejemplo.com/recurso a https://server2.ejemplo.com/recurso.

Cambio de idioma o versión según el usuario Si un usuario de España accede a https://ejemplo.com, se le puede redirigir temporalmente a https://es.ejemplo.com sin cambiar la URL permanente.

302 Found indica una redirección temporal. El navegador sigue solicitando la URL original en el futuro. Útil para mantenimiento, autenticación y gestión de tráfico dinámico.

303

Indica que el recurso solicitado no se encuentra en la misma ubicación, pero el cliente debe hacer una nueva solicitud usando el método GET a la URL proporcionada en el encabezado Location. Se usa comúnmente para evitar que un cliente reenvíe datos de un formulario después de enviarlo con POS, redirigiéndolo a una nueva URL con GET.

Usos comunes

Evitar la reenvío de formularios POST-Redirect-GET Cuando un usuario envía un formulario y luego recarga la página, sin una redirección 303 el navegador intentará reenviar el formulario. Con 303, el usuario es redirigido a una nueva página GET, evitando envíos duplicados. Ejemplo en Express.js: app.post'/formulario', req, res = // Procesa los datos... res.redirect 303, '/exito' // Redirige con GET

Redirección después de una operación de escritura Después de crear un recurso en una API con POST, en lugar de devolver los datos inmediatamente, el servidor redirige a una URL donde el cliente puede obtener el estado actualizado con `GET`.

Evitar que clientes almacenen respuestas en caché Un servidor puede usar 303 para redirigir a una página que siempre se genera dinámicamente en lugar de permitir la caché del navegador.

303 See Other redirige a otra URL con GET, sin importar el método original. Evita reenvíos de formularios POST-Redirect-GET. Útil en formularios, APIs y respuestas dinámicas no cacheables.

304

El código de estado 304 Not Modified indica que el recurso solicitado no ha cambiado desde la última vez que el cliente lo obtuvo. El servidor usa este código para decirle al navegador o a un cliente HTTP que puede usar la versión almacenada en caché, en lugar de descargar el recurso nuevamente.

Usos comunes

Optimización de carga en páginas web Los navegadores almacenan recursos estáticos (imágenes, CSS, JavaScript). Con 304, el navegador no descarga los archivos si ya tiene una versión válida.

Eficiencia en APIs y servicios web Un cliente puede enviar If-None-Match con un ETag (identificador único de una versión del recurso). Si el contenido no cambió, el servidor responde con 304, reduciendo el consumo de ancho de banda.

Mejora del rendimiento en CDN y proxys Los servidores proxy y las redes de entrega de contenido (CDN) pueden usar 304 para no descargar contenido innecesario.

304 Not Modified se usa cuando un recurso no ha cambiado puede cargarse desde la caché. Optimiza la velocidad de carga y reduce el consumo de ancho de banda. Funciona con cabeceras If-Modified-Since y If-None-Match.

305

El código 305 Use Proxy indica que el cliente debe acceder al recurso a través de un proxy específico, definido en la cabecera Location de la respuesta. Este código está en desuso por razones de seguridad, ya que podría ser explotado para ataques de tipo hombre en el medio (MITM). Los navegadores modernos lo ignoran, y ya no es recomendado su uso.

Usos comunes

Antes de quedar en desuso, se utilizaba para: Redirigir tráfico a través de un proxy para filtrar contenido o aplicar políticas de seguridad. Forzar el uso de un proxy en redes corporativas o gubernamentales. Controlar el acceso a ciertos recursos dependiendo de la ubicación del usuario.

¿Por qué está en desuso?

Riesgos de seguridad Un atacante podría redirigir a un usuario a un proxy malicioso y espiar el tráfico.

Incompatibilidad con navegadores modernos Chrome, Firefox y otros navegadores ignoran el código **305** por seguridad.

Alternativas más seguras Configuraciones de proxy a nivel de red en lugar de respuestas HTTP. Códigos de redirección como 307 si se necesita cambiar la URL de acceso.

305 Use Proxy indicaba que un recurso debía solicitarse a través de un proxy. Ya no se usa debido a riesgos de seguridad. Navegadores modernos lo ignoran y no lo implementan. Se recomienda configurar proxies en la red directamente, en lugar de usar este código.

307

El código 307 Temporary Redirect indica que el recurso solicitado se ha movido temporalmente a otra URL, pero el cliente debe seguir usando el mismo método HTTP al realizar la nueva solicitud.

Usos comunes

Redirecciones temporales sin alterar la solicitud original Si un recurso cambia de ubicación temporalmente, pero se espera que vuelva a la URL original. Evitar problemas con clientes que cambian el método HTTP Algunos navegadores convierten POST en GET con 302 Found, pero 307 mantiene el método. Balanceo de carga o mantenimiento Redirigir temporalmente a otro servidor sin afectar las solicitudes originales.

307 Temporary Redirect indica que el recurso se movió temporalmente, pero el cliente debe seguir usando el mismo método HTTP. Es más seguro que 302 cuando se quiere mantener POST, PUT, etc. Se usa en mantenimiento de sitios, balanceo de carga o cambios temporales de URL.

308

El código 308 Permanent Redirect indica que el recurso solicitado se ha movido permanentemente a una nueva URL, y el cliente debe seguir usando el mismo método HTTP al realizar futuras solicitudes.

Usos comunes

Migración permanente de un recurso o API Cuando se cambia una URL de forma definitiva.

Evitar problemas con clientes que cambian el método HTTP Algunos navegadores convierten POST en GET con 301 Moved Permanently, pero 308 mantiene el método original.

Reubicación de endpoints en APIs Si una API cambia la ruta de un recurso, se puede usar 308 para evitar romper clientes que aún usan la URL antigua.

308 Permanent Redirect indica que un recurso se ha movido permanentemente a una nueva URL. Asegura que el método HTTP original se mantenga (POST sigue siendo POST). Se usa en migraciones de sitios, cambios de URL de APIs y reubicación de recursos.

400

El código 400 Bad Request indica que el servidor no puede procesar la solicitud debido a un error del cliente. Esto suele ocurrir por: Sintaxis incorrecta en la solicitud. Datos inválidos o mal formateados. Falta de parámetros requeridos. Encabezados HTTP incorrectos o mal formateados. El cliente debe corregir la solicitud antes de intentarla nuevamente.

Usos comunes

Errores de validación Si faltan parámetros requeridos o los valores tienen un formato incorrecto. Solicitud mal estructurada Por ejemplo, si el JSON enviado tiene errores de sintaxis.

Encabezados incorrectos o ausentes Como enviar datos JSON sin el encabezado Content-Type: application/json.

Datos fuera de los límites permitidos Ejemplo: enviar un número negativo en un campo que solo acepta valores positivos.

400 Bad Request ocurre cuando el cliente envía una solicitud incorrecta o mal formada. El servidor no la puede procesar hasta que el cliente la corrija. Se usa para validaciones de datos, errores de sintaxis y encabezados incorrectos.

401

El código 401 Unauthorized indica que el cliente **no está autenticado** o **las credenciales proporcionadas son inválidas**.

Usos comunes

Autenticación requerida El usuario debe iniciar sesión antes de acceder a la API.

Credenciales incorrectas Usuario y contraseña inválidos en autenticación básica.

Token de sesión vencido o inválido El usuario debe renovar su sesión.

No se envió un token de autenticación La API espera un JWT, API Key o OAuth token.

401 Unauthorized significa que el cliente debe autenticarse primero. Se usa en APIs protegidas, sesiones de usuario y servicios OAuth. Se corrige enviando credenciales válidas o renovando el token.

402

El código 402 Payment Required indica que el acceso al recurso requiere un pago, pero la solicitud no ha sido procesada porque no se ha realizado o confirmado el pago. Aunque este código fue reservado inicialmente para sistemas de pago digital, no se usa ampliamente en la web actual. Sin embargo, algunas plataformas de suscripción y APIs lo implementan para restringir contenido a usuarios sin suscripción activa.

Usos comunes

Servicios de suscripción Plataformas como **Netflix, Spotify o periódicos digitales** pueden usarlo para restringir contenido a usuarios no suscritos.

APIs con planes pagos Servicios como OpenAI, Stripe o Google Maps API pueden devolver un 402 si se supera el límite de uso gratuito.

Pagos pendientes en plataformas SaaS Un usuario con facturas vencidas puede recibir un **402** antes de que su cuenta sea suspendida.

402 Payment Required se usa cuando un recurso **requiere pago** para acceder. Es común en plataformas de suscripción, APIs premium y servicios SaaS. Se resuelve completando el pago o renovando la suscripción.

403

El código 403 Forbidden indica que el servidor ha entendido la solicitud, pero echaza el acceso porque el cliente no tiene permisos suficientes.

Diferencia con 401 Unauthorized

401: El usuario no está autenticado o su sesión es inválida. 403: El usuario está autenticado, pero **no tiene autorización** para acceder al recurso.

Usos comunes

Restricción de acceso por roles Un usuario normal intenta acceder a un panel de administración.

Protección de recursos sensibles Intento de acceder a archivos restringidos en el servidor.

Restricciones de IP o región Un usuario fuera de un país permitido intenta acceder a un servicio.

Intento de modificar datos sin permiso Un usuario intenta borrar datos de otra cuenta sin permisos.

403 Forbidden significa que el acceso está denegado, incluso si el usuario está autenticado. Se usa en sistemas con roles, permisos de usuario y seguridad de datos. Se resuelve otorgando los permisos correctos o accediendo con otra cuenta.

404

Indica que el servidor no pudo encontrar el recurso solicitado. Esto puede deberse a: Una URL incorrecta o inexistente. Eliminación o movimiento del recurso sin redirección. Restricciones de acceso donde el servidor decide no revelar la existencia del recurso.

Usos comunes

Enlaces rotos: Una página fue eliminada sin configurar una redirección 301.

Errores tipográficos en URLs: Un usuario escribe /productos/shirt en lugar de /productos/camisa.

Recursos eliminados o movidos: Un archivo descargable ya no está disponible.

Restricción de acceso sin revelar existencia: Un servidor puede devolver 404 en lugar de 403 para ocultar un recurso privado

404 Not Found significa que el recurso no existe o no puede ser encontrado. Puede ser causado por errores de URL, eliminación de contenido o enlaces rotos. Se soluciona corrigiendo la URL, agregando redirecciones o restaurando el recurso.

405

Indica que el recurso solicitado existe, pero no permite el método HTTP utilizado, por ejemplo intentar 0POST en una URL que solo permite GET, intentar DELETE en una API que solo permite PUT o PATCH.