URL查询参数以及松懈如何在Web上产生实际需求

DWiki(流浪思想背后的代码)的不同寻常之处之一是，它严格验证在URL上接收的查询参数，包括在普通页面的HTTP GET请求上接收的查询参数。如果HTTP请求具有意外且不受支持的queryParameters，这样的GET请求通常会失败。当我做出这个决定时，这似乎是谨慎和保守的做法，但这种谨慎在现代网络上被证明是一个错误。实际上，所有类型的站点都会生成带有各种附加查询参数的URL版本，并将它们提供给人们，然后期望它们能够正常工作。如果您的网站拒绝配合，(一些)人们将无法看到您的内容。(#**$$}{##**$$}{#**$$}。在今天的Web上，您需要接受(然后忽略)URL上的任意查询参数。

(对于NNlike'；04'；和'；09'；的各种值，今天的新查询参数是'；s=nn&39；。我不确定是什么生成了这些URL，但可能是Slake。)。

你可能想知道我们是怎么走到这一步的，这是一个行为松懈的故事(或者，如果你愿意，在你接受的东西上是自由的)。在一开始，Apache(用于静态网页)和早期的Web应用程序通常都忽略URL上的额外查询参数，至少在GET请求上是这样。我怀疑其他早期的Web服务器也在这里模仿Apache，但与Apache相比，我对它们行为的了解较少。我猜测这种行为不是故意的，它只是实现Apache和早期Web应用程序的最简单方式；您只关注您关心的内容，而没有费心明确检查是否没有提供其他任何内容。

当人们注意到这种行为司空见惯时，他们就开始使用它。我相信最早的用途之一是prembedding'；在那里这个链接被分享给你自己的网络分析(Cf)信息，或者是基于你的日志，或者是使用嵌入在页面中的JavaScript。在这种情况下，一旦这种情况变得足够普遍，其他人就开始为你有用地标记通过他们共享的链接，这就是为什么我开始看到各种各样的入站请求的查询参数，尽管我从未发布过这样的URL。Web开发人员不会让有吸引力的麻烦持续太久，所以足够多的人坚持使用额外的查询参数到你的URL，这些参数大多是给他们的，而不是给你的。Facebook可能是这里最早推出参数的网站之一，但从那时起，其他网站也加入了这一行列(就像我最近看到的这些参数一样)。

在这一点上，其他网站和服务在通过它们的URL中添加随机查询参数的做法非常普遍，接受随机查询参数对于任何希望看到广泛使用而不会激怒操作它的人的网络内容服务软件来说，几乎是一种实际要求。如果你像DWiki一样固执己见，拒绝接受部分或全部请求，你就会放弃一些来自真人的请求，令人失望。

URL处理的这一实际要求没有记录在任何规范中，而且它可能没有出现在大多数最佳实践文档中。编写新的网络服务系统的人试图变得严格、安全和谨慎，但他们会以艰难的方式了解到这一点。

一般而言，系统的实际实现中的任何松懈都可能造成类似的实际需求螺旋式上升。允许的和对人们有用的东西将被使用，然后支持成为一种要求。尤其是在像网络这样的分布式系统中，任何收紧规则的尝试最初只会得到少数网站的支持。这些网站会被绝大多数允许松懈行为并支持它的网站压倒，因为当绝大多数网站工作而少数人不工作时就会出现这种情况。