Resumen

  • El 305 Use Proxy de 1997 pedía repetir la solicitud a través del proxy indicado en el campo Location.
  • La versión de 1999 acotó la orden a una solicitud y a respuestas del servidor de origen; la de 2014 desaprobó el mecanismo por el riesgo de configurar un proxy dentro del propio intercambio.

Vas a una tienda a preguntar por un libro. En lugar de atenderte, la tienda te manda a un representante que acaba de elegir por ti. Su dirección viene escrita en la respuesta. HTTP tuvo un código para semejante maniobra: 305 Use Proxy. El servidor podía nombrar un intermediario y pedir al cliente que repitiera por allí la solicitud. No cambiaba el libro; cambiaba quién recibía primero la conversación.

RFC 2068, la especificación HTTP/1.1 de enero de 1997, presentó la regla sin mucha ceremonia. La respuesta debía traer en Location la URL del proxy y el receptor debía volver a pedir el recurso a través de él. Un proxy, según el propio RFC, recibe peticiones y las reenvía al destino, con capacidad de reformular parte del mensaje. Su presencia en la ruta tiene consecuencias que un simple cartel de «nos hemos mudado» no produce.

Por eso 305 era una redirección peculiar. 301 señala otra dirección para el recurso. 305 pretendía mantener el recurso donde estaba y cambiar el camino para llegar a él. Elegir ese camino suele depender de la configuración del cliente y de la confianza en los equipos que median la petición. La respuesta del destino reclamaba voz sobre una decisión de ruta.

El RFC 2616 de junio de 1999 añadió dos candados. 305 servía para esa única petición, y solo el servidor de origen podía generarlo. Una nota reconocía que el RFC de 1997 no había dejado claras esas limitaciones y advertía de consecuencias importantes para la seguridad si se ignoraban. El primer candado evitaba convertir una respuesta aislada en la configuración permanente del navegador. El segundo impedía que un intermediario eligiera a otro haciéndose pasar por el origen de la orden.

Quedaba la incomodidad central: el proxy se configuraba dentro de la misma conversación que pretendía desviar. RFC 7231, publicado en 2014, desaprobó 305 y señaló expresamente las preocupaciones de seguridad que provocaba esa configuración dentro del canal HTTP. La objeción apuntaba al propio volante: una respuesta HTTP pretendía entregar a un proxy elegido por el servidor la siguiente petición del cliente.

En RFC 9110, de 2022, el número aún aparece en el inventario de estados, marcado como desaprobado. Los protocolos conservan fósiles útiles: permiten leer mensajes antiguos sin concederles otra vez el poder que se les retiró. La caseta del intermediario sigue dibujada en el mapa; ya no es una indicación vigente para recorrerlo.

La ruta de una petición también es parte de su significado práctico. Antes de llegar al servidor, un proxy puede ver la solicitud que pasa por sus manos. 305 permitía que una respuesta nombrara ese puesto intermedio. La norma primero levantó barandillas en 1999 y después retiró el desvío. La pregunta que dejó escrita es más grande que el número: ¿quién decide qué máquina se sienta entre el lector y su destino?