反追踪战争：为什么一位开发者禁止了查询字符串
反追踪战争：为什么一位开发者禁止了查询字符串
在无处不在的数字监控时代，URL 已不仅仅是一个地址；它已成为一种追踪手段。从 utm_source 到 fbclid，许多平台会自动在发出的链接中附加长串的追踪参数，且通常未经目标网站或用户的同意。
最近，开发者 Chris Morgan 通过在其个人网站上全面禁止未经授权的查询字符串，引发了一场技术和哲学上的辩论。通过配置其服务器拒绝任何包含其未明确定义的查询字符串的请求，Morgan 正在对“URL 篡改”采取强硬立场。这一举动引发了关于谁拥有 URL 以及服务器自主权与 Web 互操作性之间界限何在的基本问题。
反对滥用查询字符串的理由
Morgan 的主要动机是对未经请求的追踪行为的拒绝。当第三方网站将 ?ref=example.com 或复杂的 UTM 参数附加到指向他网站的链接时，他们本质上是在利用他自己的基础设施来促进他们的追踪工作。
正如 Morgan 所言：
"I don’t like people adding tracking stuff to URLs. Still less do I like people adding tracking stuff to my URLs... UTM parameters are for me to use, not you."
对于许多人来说，这是一个“超文本礼仪”的问题。附加追踪 ID 的做法创造了“怪物”——长度达数千个字符的 URL，使其难以分享、阅读或信任。用户经常发现自己在聊天或论坛分享链接之前，必须手动清除地址栏中的这些参数，以避免传递追踪令牌。
技术实现与 414 响应
在技术上，Morgan 通过他的 Caddyfile（Caddy Web 服务器的配置文件）实现了这一禁令。有趣的是，他选择使用 414 URI Too Long 错误来响应这些请求。虽然对于意外的参数，使用 404 Not Found 或 400 Bad Request 可能在语义上更准确，但 Morgan 承认选择 414 部分是出于幽默感。
这一实现突显了一个关键的技术点：服务器对如何处理传入请求拥有绝对控制权。如果服务器被配置为忽略查询字符串，它通常只是丢弃它们。然而，通过积极地拒绝它们，网站所有者将一种被动的无视转变为了一种积极的抗议。
伟大的辩论：鲁棒性 vs. 严格性
禁止查询字符串的决定引发了开发者社区的分歧，主要集中在两种核心观点：
支持宽松性的观点
一些人认为，Web 的成功建立在“自由放任”的方法之上。在这种观点下，URL 是一个“无需许可的超语言”，链接到某个网站的人应该有权根据自己的意愿构建 URL。
对该禁令的批评者认为，用错误页面惩罚用户是适得反药的。如果用户点击了一个由企业平台添加了追踪参数的链接，受害者是用户，而不是添加追踪代码的公司。一位评论者建议，与其使用错误，网站可以显示一个警告，或者实施一种工作量证明（PoW）机制来威慑机器人，同时仍允许人类用户访问内容。
支持服务器主权的观点
相反，有人认为，在未经服务器所有者同意的情况下操纵 URL 是一种违反协议的行为。从这个角度来看，查询字符串是 URL 的一部分，与路径（path）同等重要；向路径添加随机参数会被视为“未定义行为”，因此向查询字符串添加参数也应被同样对待。
实际影响与替代方案
对于那些觉得追踪 URL 的“怪物”令人令人沮丧，但又还没准备好实施全面禁令的开发者，存在一些折中方案：
- Referrer Policy: 使用严格的
Referrer-Policy（例如strict-origin-when-cross-origin）允许网站所有者在主机层面查看流量来源，而无需查询字符串，同时尊重用户隐私设置。 - Client-Side Stripping: 一些用户使用书签脚本（bookmarklets）来清除查询参数。一个建议的代码片段是：
(()=>navigator.clipboard.writeText(location.origin+location.pathname))(); - Selective Validation: 与其进行全面禁令，一些开发者会验证特定的已知参数，并仅在提供无效或恶意值时才发出
40x错误。
结论
无论被视为是对隐私的保卫战，还是被视为一种“愚蠢的古板”，禁止查询字符串的行为都提醒了人们，在开放、松散耦合的 Web nature 与个人对数字空间的自主权之间存在着紧张关系。随着追踪手段变得越来越激进，那些想要“篡改” URL 的人与那些想要保持 URL 干净的人之间的冲突很可能会加剧。