Prohibí las cadenas de consulta

• Chris Morgan decidió bloquear por completo las cadenas de consulta no autorizadas en su sitio, y la implementación actual está en su Caddyfile
• No quiere que se agreguen parámetros de seguimiento como ?ref=example.com a sus URL, y considera que, si hace falta, basta con revisar el encabezado Referer
• Considera que UTM parameters como ?utm_source=example&utm_*&c.* son para uso del propietario del sitio, no para que terceros los agreguen
• Actualmente el sitio no usa cadenas de consulta en absoluto, y si en el futuro las usa, planea permitir solo parámetros conocidos
• La URL final quedó como /no-query-strings, y no eligió /%3F por problemas con la reescritura try_files de Caddy

---

Bloqueo de cadenas de consulta no autorizadas

• Chris Morgan decidió bloquear por completo las cadenas de consulta no autorizadas en su sitio
• No quiere que se agreguen parámetros de seguimiento como ?ref=example.com a sus URL, y considera que, si hace falta, basta con revisar el encabezado Referer
• Considera que UTM parameters como ?utm_source=example&utm_*&c.* son para uso del propietario del sitio, no para que terceros los agreguen
• Actualmente este sitio no usa cadenas de consulta en absoluto, y si en el futuro las usa, planea permitir solo parámetros conocidos
• En el pasado usó URL de invalidación de caché en hojas de estilo con formas como ?t=…, ?h=…, pero considera aceptable que esas solicitudes se rompan
• Este bloqueo está implementado actualmente en el Caddyfile

Proceso de elección de la URL

• Plan de usar /?

  • Al principio, la tentación de publicar esta página en https://chrismorgan.info/? era grande
  • Por tratarse de una forma con ruta vacía y consulta vacía, habría roto muchas suposiciones comunes pero erróneas, y podría haber puesto en aprietos a algunas herramientas
  • curl parecía eliminar indebidamente el signo de interrogación final en la línea de comandos, y no probó el uso con bibliotecas
  • Al final decidió respetar el concepto de ruta y ser más indulgente con la gente, sobre todo porque considera que ya está empujando a Caddy en una dirección bastante incómoda

• Plan de usar /%3F

  • El siguiente plan era publicarlo en /%3F, donde la ruta es ? y no hay consulta
  • Sin embargo, había un problema en Caddy que impedía manejarlo cuando intervenía la reescritura try_files
  • El issue relacionado es try_files rompe rutas que contienen caracteres como ? y %

• Elección final

  • La URL final quedó como /no-query-strings
  • /? o /%3F podrían usarse más adelante para otro propósito relacionado con cadenas de consulta

[GN⁺]

Comentarios en Hacker News

• Me dio curiosidad, así que volví a revisar los estándares W3C de HTML y URL, y para mi sorpresa el formato de la cadena de consulta no está definido por separado más allá de la codificación porcentual
  Se puede confundir la cadena de consulta con una cadena de consulta “form-urlencoded”[0], pero eso es solo uno de los formatos interoperables. En general, una cadena de consulta es una cadena arbitraria codificada con porcentajes[1] que va después del ? de una URL, y es otra propiedad del objeto URL de HTML que puede usarse para generar la respuesta
  El objeto URLSearchParams es el resultado de analizar la cadena de consulta con un parser form-urlencoded, pero eso no es más que una capa de interoperabilidad para JavaScript
  Sinceramente, antes de mirar el estándar estaba listo para discrepar, pero el estándar era bastante claro. Incluso responder con 404 ante una cadena de consulta inesperada puede ser apropiado. La cadena de consulta es parte de la API de URL tanto como la ruta, y la mayoría probablemente estaría de acuerdo en que añadir cadenas arbitrarias a una ruta no es buena idea y constituye un comportamiento no definido
  [0]: https://url.spec.whatwg.org/#application/x-www-form-urlencod...
  [1]: https://url.spec.whatwg.org/#url-class

  • Antes era bastante común que los CMS o foros dejaran solo un index.php y manejaran todo el enrutamiento con la cadena de consulta
    Claro, usaban formato form-urlencoded; la gente tampoco era salvaje. Por eso salían URLs como index.php?p=home, index.php?p=shop o index.php?action=showthread&forum=42&thread=17976. En una estructura así, se ve enseguida que la respuesta correcta para parámetros de consulta desconocidos sería un 404
    De hecho, muchos sitios todavía funcionan así, solo que lo esconden detrás de unas cuantas reglas de reescritura de Apache/nginx por cuestiones de SEO
  • Sí, las URL no tienen tanta semántica. La intención de usar la ruta para datos jerárquicos y la consulta para datos no jerárquicos parece bastante clara, hay una convención fuerte y algunas bibliotecas incluso la apoyan o la imponen, pero reglas reales no hay
    Al final, una URL no es más que una cadena que el servidor decide cómo procesar
    Lo realmente gracioso de esta discusión es preocuparse por los efectos secundarios de responder con 404 y al mismo tiempo olvidar por completo cuánto tiempo las rutas no significaron nada en la historia de la web. Ahora la ruta ganó. Ya casi nadie empieza de cero con URLs como /item?id=…. ¡Qué bien!
  • Me parece que un 400 genérico sería mejor. No es que no se haya encontrado la página, sino que se envió una solicitud no permitida
    Se lee como “corrige la solicitud y vuelve a intentarlo”, y así lo uso también en las APIs que ofrezco. Lo prefiero a 406 porque no se trata de un problema que yo no pueda procesar. Si alguien intentó romper algo agregando cosas a la cadena de consulta o no armó la solicitud según la documentación, la responsabilidad es del solicitante
  • La propuesta No-Vary-Search permite especificar qué partes de la consulta son relevantes
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
    Por ejemplo, desde el punto de vista del caché, url?a=b&c=d podría considerarse equivalente a url?c=d&a=b
  • Un estándar no es más que un comportamiento ampliamente aceptado que alguien dejó por escrito en alguna parte
    Hay muchísimas convenciones que nunca se documentaron como estándar formal, pero si no las sigues todo se rompe por todos lados, y también hay muchos “estándares” que, si los sigues al pie de la letra, te hacen quedar como tonto
    En el caso del post original, lo único que se rompe es la experiencia de quien quería visitar ese sitio, y probablemente simplemente le dará atrás en el navegador y seguirá con su vida. Cada quien decide si ese nivel de daño le parece aceptable. Pero que ningún estándar lo prohíba no significa que por definición esté permitido; y al revés, que un estándar lo prohíba no hace que mágicamente quede prohibido

• Según entendí, al autor le molestó que otros sitios web agreguen una cadena de consulta como ?ref=origin.com a enlaces que apuntan a su sitio
  No entiendo qué beneficio obtiene el sitio de origen ni qué perjuicio sufre el sitio del autor
  El comportamiento de ambas partes me parece completamente confuso
  Entiendo que, cuando se gestionan campañas publicitarias, Google agregue cadenas de consulta UTM para rastrear desde qué campaña llegó un usuario. Ahí el origen y el destino están cooperando. Pero aquí el origen está agregando algo sin razón aparente. ¿Por qué?

  • Desde el punto de vista del sitio de origen, es marketing. La idea es que el autor vea en la cadena de consulta ref que está llegando bastante tráfico desde xyz.com y piense en anunciarse allí o hacer alguna alianza
    Sinceramente, para sitios de nicho o startups puede ser bastante útil. Me ha tocado estar en ambos lados de conversaciones que empezaron al ver este tipo de valores en analítica web: una vez yo contacté al otro sitio al ver el tráfico entrante, y otra vez me contactaron desde un sitio al que yo había enlazado. En ambos casos terminó en alianzas beneficiosas para ambas partes
    También entiendo en cierta medida el argumento de privacidad, pero esto no aporta más información que el encabezado estándar Referer. Solo que se vuelve mucho más visible si usas herramientas de analítica como Simple Analytics o Plausible
  • En general estoy en contra del rastreo. El rastreo normalmente va contra el interés de las personas
    Agregar cadenas de consulta suele usarse para rastrear. Basta ver que existen funciones como “copy clean link” de Firefox o Enhanced Tracking Protection, que elimina de forma preventiva algunos parámetros UTM, para notar que mucha gente no lo quiere
    Algunos sitios participan voluntariamente en lo que llamo a la ligera la “economía del rastreo”, porque el destinatario puede ver en sus logs que mucha gente llegó desde cierto sitio y actuar de una manera que beneficie a ese sitio
    Rechazar las cadenas de consulta es una forma sencilla de protesta contra ese sistema
  • Si un sitio web popular agrega ese parámetro, el sitio de destino puede saber fácilmente quién le está enviando tráfico, y eso puede servir de base para patrocinios o acuerdos de afiliación

• Por la descripción de “una pequeña consola web descentralizada, autoalojada, que permite a los visitantes explorar sitios y páginas interesantes recomendados por una comunidad de operadores de sitios web personales independientes”, antes a eso se le llamaba un Webring. Solo que no sonaba tan elegante
  Uno de los problemas que tuve al desarrollar un framework de aplicaciones open source fue que algunos hostings con FastCGI no respetaban el encabezado Auth, así que no me quedaba otra que pasar el token en la consulta. Era horrible, porque al copiar y pegar direcciones web el token terminaba incluido muy seguido. Tal vez eso ya se haya arreglado
  En backends bajo mi control y que no tienen que exponerse al público, uso encabezados

  • ¿Quieres decir que escribiste el framework de aplicaciones open source con fcgi-app y que, por ejemplo, Apache rompía el encabezado Auth?
    Me da curiosidad si podrías explicar esta parte con más detalle. Técnicamente suena a que el registro PARAM no estaba entregando el valor esperado

• Dice: “Así que en este sitio intenté una prohibición general: nada de cadenas de consulta no aprobadas”, pero parece que su sitio devuelve 414 si la solicitud incluye una consulta, y me parece una mala elección
  Si esta protesta pretende defender a los usuarios, ¿por qué castigar a usuarios que probablemente ni siquiera controlaban esa cadena?
  ¿No sería mejor usarlo como una señal para enseñarles cómo tomar esa decisión por cuenta propia mediante herramientas del navegador o algo así?

  • “Podrías decir que estoy abusando de 414 URI Too Long. Mi respuesta es que así es más gracioso. Otras opciones que consideré fueron:
    400 Bad Request, que encaja como error genérico del cliente, pero no tiene gracia
    402 Payment Required, aunque sinceramente estaría dispuesto si me pagaran para que ciertas URL con cadena de consulta funcionen
    404 Not Found, pero eso facilita demasiado que se generen efectos secundarios y no transmite la sensación de ‘el formato de la solicitud está mal’ que quiero comunicar
    303 See Other sin encabezado Location. Hoy en día es muy raro, pero es legítimo. Al menos en RFC 2616 lo era (“The different URI SHOULD be given by the Location field in the response”). Pero en 7231 y 9110 eso cambió a una redacción que da por sentada la presencia del encabezado Location (“… as indicated by a URI in the Location header field”). En cambio, 301, 302, 307 y 308 dicen “the server SHOULD generate a Location header field”. En cualquier caso, me parece perfectamente aceptable un See Other sin encabezado Location. Pero URI Too Long me pareció más gracioso”
    https://chrismorgan.info/no-query-strings?foo
  • Hace muchísimo tiempo, pero me suena que había una versión de las páginas de servidor PLSQL que devolvía 500 si le pasabas una cadena de consulta desconocida

• En la parte que dice “Podrías decir que estoy abusando de 414 URI Too Long. Mi respuesta es que así es más gracioso. Otras opciones que consideré fueron...”, otra posibilidad habría sido 418 I'm a teapot. Después de todo, las teteras normalmente tampoco soportan cadenas de consulta

  • La verdad, 400 “Bad Request” o 403 “Forbidden” también parecen opciones defendibles. Es raro que no exista un código de respuesta de error específico para parámetros URI
    Hay varias opciones que parecen adecuadas, pero al mirarlas de cerca no lo son: 406 “Not Acceptable” se basa en encabezados de negociación de contenido; 409 “Conflict” suele usarse sobre todo para solicitudes WebDAV; y 411, 422, 431 y otras son para condiciones específicas que no aplican aquí
    Los errores de la serie 300 o 500 también son inadecuados. Esto no es una reubicación ni un fallo del lado del servidor, sino un problema con la solicitud del cliente
    La tetera o lo demasiado largo parecen los mejores candidatos
  • Claro que sí. Por ejemplo, puedes dejar caer una cuerda desde arriba y consultar el nivel de agua de la tetera, o enrollarla alrededor para consultar su circunferencia
  • Pero yo no soy una tetera. No me gusta el té

• Por el tono de este artículo y el de Chris, da la impresión de que incluir este tipo de parámetros de consulta fuera dañino, pero no entiendo cómo lo sería
  Entiendo que puede romper algunas URL, y solo por eso ya hay motivos suficientes para no hacerlo. Aun así, me parece una molestia menor. ¿Alguien podría explicarlo?

  • Hay tres maneras de verlo
    Desde una postura de purismo técnico, modificar una URL es técnicamente incorrecto aunque por convención se tolere. En esencia, una URL debería tratarse como un valor opaco
    Desde una perspectiva social, es rastreo, y los hilos hermanos ya lo explican bien, así que no lo repetiré
    Desde la perspectiva del ruido, contribuye a ocultar las partes que sí le importan al usuario y a volver la URL tan difícil y complicada que la gente común deja de prestarle atención
  • Si lees sobre los problemas relacionados con el encabezado HTTP Referer, queda claro por qué a la gente no le gusta: https://en.wikipedia.org/wiki/HTTP_referer
    Hay muchas razones por las que uno no querría que un sitio supiera dónde estuvo antes de llegar ahí. Básicamente estás compartiendo tu historial de navegación con el sitio que visitas
    Por eso el encabezado HTTP Referer ha recibido muchas actualizaciones, incluyendo restricciones sobre cuándo se envía y opciones para desactivarlo por completo
    Si agregas la misma información como parámetro en la URL, estás eludiendo esas reglas existentes y las posibilidades de rechazarlo. Simplemente debería usarse el estándar
  • No hay ninguna razón. Esa información se puede descartar sin más
    Es una postura ridículamente extrema, y no explica bien cómo eso llevaría a una web mejor
  • Lo curioso es que ninguno de estos sitios tiene función de búsqueda. La búsqueda es una función importante de accesibilidad y un caso de uso claro y legítimo de las cadenas de consulta
  • Hay varias razones. El usuario no dio consentimiento para ser rastreado, y este tipo de parámetros de consulta es información de rastreo. Además, puede que el administrador del sitio no quiera que el tráfico entrante quede rastreado
    Lo segundo quizá cueste más entenderlo, pero en mi caso no quiero en absoluto que en los logs quede información que pueda perjudicar a los usuarios
    Personalmente, cuando quiero copiar un enlace y mandarlo por mensaje, detesto que venga con un código de rastreo el doble de largo que la URL original. O tengo que borrar todo eso a mano, o dejar que quien lo reciba se pregunte qué demonios son esas cadenas aleatorias que ocupan toda la pantalla
    Viola la privacidad del usuario, ofrece una mala experiencia de uso y, sobre todo, nadie lo pidió

• Como la fuente original todavía no se había discutido en HN, puse ese enlace (https://chrismorgan.info/no-query-strings) arriba del todo y moví el enlace a la respuesta (https://susam.net/no-query-strings.html) a la descripción superior
  Ambos están bien, pero me parece justo darle prioridad al original

• La mayoría de los sitios por aquí que todavía usan consultas GET son sitios de cobro de impuestos administrados por gobiernos locales, que van pasando variables de un lado a otro después del inicio de sesión
  La verdad, me molestan mucho más esos parsers de rutas que hacen exactamente lo mismo que una solicitud GET pero fingen ser una URL real

• Las cadenas de consulta sí sirven. Por ejemplo, para búsqueda de archivos o para otros tipos de archivos dinámicos, pero no deberían agregarse a URLs que no las esperan
  Por eso me parece correcto rechazar solicitudes a las que se les añaden cosas como UTM
  Si no se esperaba una cadena de consulta y aun así está presente, 404 me parece la respuesta con más sentido, aunque 400 también podría ser apropiado