305

Use Proxy

El código HTTP más obsoleto y peligroso. Proxies, seguridad y por qué nadie debería usar esto jamás.

⚠️ Redirection

📋 ¿Qué narices es esto?

El código 305 Use Proxy es el "vete por ahí pero pasando por aquí primero" de HTTP, y también el más peligroso y obsoleto de todos los códigos de estado. Fue diseñado para que el servidor le dijera al cliente "usa este proxy para acceder al recurso", pero resultó ser un agujero de seguridad del tamaño de un camión. Como darle a un extraño las llaves de tu casa y decirle "confía en mí".

Este código apareció en HTTP/1.1 con las mejores intenciones, pero rápidamente se dieron cuenta del problema: permitía que cualquier servidor forzara al cliente a usar un proxy específico, abriendo la puerta a ataques man-in-the-middle, interceptación de datos y toda clase de travesuras maliciosas. Es como si Amazon te dijera "para comprar, pasa primero por la casa de mi primo".

El 305 teóricamente debería aparecer en:

  • Configuraciones de proxy corporativas (nunca funciona bien)
  • Redes internas con proxies obligatorios (problemático)
  • Sistemas de filtrado de contenido (inseguro)
  • Balanceadores de carga mal configurados (error)
  • En la práctica: prácticamente nunca

🚨 ¡PELIGRO!

El 305 está oficialmente DESACONSEJADO desde hace años. Los navegadores modernos lo ignoran o muestran errores. Si ves un 305 en producción, algo está muy mal configurado. ¡Arréglalo YA!

La tragedia del 305 es que parecía buena idea en papel: "el servidor sabe qué proxy usar mejor que el cliente". Pero en la realidad permitía ataques donde un servidor malicioso redirigía todo tu tráfico a través de sus propios proxies. Es la diferencia entre una recomendación de ruta y un secuestro de tu GPS.

🔧 Cómo NO implementar esto

🚫 Para servidores (NO hagas esto)

  1. NO respondas con 305: Los navegadores lo ignorarán o fallarán.
  2. NO fuerces proxies externos: Es un riesgo de seguridad masivo.
  3. NO uses Location con proxies: Abre vectores de ataque.
  4. Usa 302/307 en su lugar: Para redirecciones normales.
  5. Configura proxies en infraestructura: No en código HTTP.

📱 Para desarrolladores (alternativas seguras)

  1. Configura proxies en networking: Nivel de sistema/infraestructura.
  2. Usa proxy reverso (Nginx/Apache): Transparente para el cliente.
  3. Implementa load balancing: En lugar de redirecciones de proxy.
  4. Detecta y maneja 305: Como error en tu aplicación.
  5. Educate sobre alternativas: Proxies seguros y modernos.

Problemas típicos con 305

  • Riesgo de seguridad extremo:
    Permite que un servidor fuerce al cliente a usar un proxy arbitrario, abriendo la puerta a ataques man-in-the-middle y robo de datos.
  • Ignorado por navegadores modernos:
    La mayoría de navegadores y clientes HTTP ignoran el 305 o muestran un error, por lo que no sirve para nada útil hoy en día.
  • Configuraciones accidentales:
    A veces aparece por error en proxies o balanceadores mal configurados. Si ves un 305, probablemente es un fallo de infraestructura.
  • No es cacheable:
    No se debe cachear nunca una respuesta 305. Si lo haces, puedes romper toda la navegación del usuario.

🚀 Respuesta rápida para emergencias

🔥 Si ves un 305 en producción:
1. Revisa la configuración de proxies y balanceadores.
2. Busca reglas accidentales en .htaccess, nginx o firewalls.
3. Elimina cualquier lógica que devuelva 305.
4. Reinicia servicios tras el cambio.
⚡ Si un cliente falla al navegar:
1. Comprueba si recibe un 305.
2. Actualiza el navegador o cliente HTTP.
3. Contacta con el administrador del servidor.
4. Usa herramientas como curl o DevTools para depurar.
🎯 Alternativa segura:
Configura proxies a nivel de red o usa proxy reverso (Nginx, Apache). Nunca fuerces proxies vía HTTP.