Http URL中的尾随符号和是否合法？

像这样的URL

http://localhost/path?a=b&c=d

很好-但是带尾随符号的同一URL的状态是什么

http://localhost/path?a=b&c=d&

例如，JavaServletAPI在不允许的地方允许它（即它抛出一个错误）

---

我试图从中找到答案，但不确定如何解析它们的语法。

我认为有一条不成文的规则，所有RFC都几乎不可能理解。你不是第一个不能解析语法的人，而且——依我的拙见——Spray也失败了

---

尾随的“与”符号没有问题。它是URI中用于分隔参数的合法字符。尾随符号和可能毫无意义，但它不是无效的。Spray应该（再一次，仅在我看来）完全忽略它

URI语法规范用于通用URI。它允许任何形式的行为。我不知道有任何规范实际指定了符号和分隔键=值对。我认为这只是惯例。例如，我知道PHP提供了一个使用不同分隔符的选项。但现在，每个人都在需要键值对时使用符号和分隔符。您仍然偶尔会遇到将其用作简单字符串的东西，例如。这是完全正确的

不过，基本答案是

&

在查询字符串中的任何位置都有效，包括末尾

---

取消限制RFC语法，或者为什么

&

在查询字符串中的任何位置都有效：

首先，你有

query       = *( pchar / "/" / "?" )

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

（因此，查询字符串由任意数量的

pchar

和文本斜杠和问号组成。）

回去吧，你有

query       = *( pchar / "/" / "?" )

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

更早些时候

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
            / "*" / "+" / "," / ";" / "="

---

因此，文本

&

位于

pchar

中的

子文档中，因此如果您在纯文本电子邮件中有如下url，则在
查询中它是有效的：

请点击此链接
https://server/doc?param=test.
重置您帐户的密码

它成为一个有用的功能，因为如果最后一个参数以“.”（点+空格）结尾并放在电子邮件中，所有类型的邮件客户端都会假定该点以句子结尾，并在检测到URL时将其从他们添加的可单击链接中排除

并非所有邮件客户端都支持将链接置于双引号或尖括号之间，默认URL编码会保留点，因为它不是保留的URI字符

最后，我在URL上添加了一个尾随符号“&”，以解决这个问题，称我为疯子，但它确实有效。
值得注意的是，该规范将用户转发到ABNF正式化的地方。是的，语法需要一些时间来适应，但一旦你理解了参考文献的位置，就不会那么糟糕了。不，它们几乎不可能理解=D