在附加查询字符串时总是跳过尾部斜杠是否安全？
也就是说，我可以用吗
http://example.com?querystring
代替：
http://example.com/?querystring
？我使用过的所有虚拟主机都支持此方法，但假设所有服务器环境都支持此方法是否安全？标准吗？
【问题讨论】：
Location 标头，它会将其发送给客户端，客户端将负责正确理解您的原始意图。客户端将尝试通过在根位置添加斜杠来“修复”您的 URL，如果这是它的设计目的。无论您在 URL 栏中输入什么内容，任何浏览器（无论是否现代）发送的所有请求都将始终以 / 开头。
标签： url query-string
按照现代规范，是的，允许跳过斜线，这与 accepted answer 此处声称的相反。
虽然接受的答案正确引用了 RFC 1738（20 多年前发布！），但它错误地声称 RFC 2396（1998 年发布）需要斜杠，并忽略了 两个 这两个规范都有反过来又被RFC 3986 淘汰，2005 年发布（距离接受的答案还早几年），最近又被WhatWG URL Standard 淘汰，两者都允许省略斜杠。
让我们依次考虑这些规范，从最早到最新：
隐式要求specifying that it may be omitted if the URL contains neither a path nor a query string 包含斜线（此处称为searchpart）。下面的粗体字是我的：
HTTP URL 采用以下形式：
http://<host>:<port>/<path>?<searchpart>其中
<host>和<port>如Section 3.1 中所述。如果：<port>省略，端口默认为80。没有用户名和密码 允许。<path>是 HTTP 选择器，<searchpart>是查询 细绳。<path>是可选的，<searchpart>和它的 前面的“？”。 如果<path>和<searchpart>都不存在，则“/” 也可以省略。
这里可以省略斜线。该 RFC 将一些在方案后没有双斜杠的奇怪 URL 语法合法化，但如果我们忽略这些（它们是在规范的 BNF 中带有 opaque_part 的那些）并坚持使用包含host，然后我们发现absoluteURI是这样定义的……
absoluteURI = scheme ":" ( hier_part | opaque_part )
hier_part 看起来像这样：
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path 看起来像这样：
net_path = "//" authority [ abs_path ]
abs_path 又被定义为以斜杠开头。请注意，abs_path 在上述语法中是可选 - 这意味着scheme://authority?query 形式的 URL 是完全合法的。
附录G.2. Modifications from both RFC 1738 and RFC 1808暗示了这一变化的动机：
问号“？”字符已从允许的集合中删除 权限组件中用户信息的字符，因为测试 表明许多应用程序将其视为保留用于分离 来自 URI 其余部分的查询组件。
换句话说 - 现实世界中的代码假设 URL 中的第一个问号，任何地方，都标记了查询字符串的开头，因此规范被务实地更新以与现实保持一致。
同样，可以省略斜线。规范通过说每个包含权限（主机）的 URI 中都需要一个“路径”来表达这一点，并且该路径必须要么以斜杠开头或由没有字符：
通用 URI 语法由一个分层序列组成 称为方案、权限、路径、查询和 片段。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-emptyscheme 和 path 组件是必需的，尽管路径可能是 空（无字符）。当权威存在时，路径必须 可以为空或以斜杠（“/”）字符开头。
为了完整起见，请注意path-abempty 稍后是这样定义的：
path-abempty = *( "/" segment )
这确实允许它不包含任何字符。
同样，省略斜线是可以接受的，尽管这次我们没有 BNF 可看，而是需要阅读大量散文。
Section 4.3 告诉我们：
absolute-URL string 必须是以下之一
- URL-scheme string 是 ASCII case-insensitive 匹配 special scheme 而不是 ASCII case-insensitive 匹配 "
file"，后跟 ":" 和 scheme-relative-special-URL string- URL-scheme string 不是ASCII case-insensitive 匹配special scheme，后跟“：”和relative-URL string
- URL-scheme string 是 ASCII case-insensitive 匹配“文件”，后跟“：”和 scheme-relative-file-URL string
任何可选的后跟“？”和一个 URL 查询字符串。
由于 HTTP 和 HTTPS 是 special schemes，任何 HTTP 或 HTTPS URL 都必须满足这三个选项中的第一个 - 即 http: 或 https: 后跟 scheme-relative-special-URL string，其中：
必须是“
//”，后跟valid host string，后跟可选的“:”和URL-port string，后跟可选的path-absolute-URL string。
path-absolute-URL string 被定义为以斜杠开头，但在上面的绝对 URL 字符串的定义中是显式可选的；因此，允许从主机直接访问“?”和查询字符串，因此像http://example.com?query 这样的 URL 是合法的。
当然，这些都不能保证每个 Web 服务器或 HTTP 库都会接受此类 URL，也不会将它们视为在语义上等同于包含斜杠的 URL。但就 spec 而言，跳过斜线是完全合法的。
【讨论】：
?之前添加一个斜杠：例如在加载页面时将https://stackoverflow.com?test替换为https://stackoverflow.com/?test。我可以防止这种行为吗？
没有。跳过斜线是不正确的。它可能适用于现代浏览器：但是，这并不正确。
请参阅RFC1738 - URL 和 RFC2396 - URI.
按照 RFC1738 的格式（我在这里排除了架构格式）：
//
: @ : /
它继续指出：
...主机（或端口）和 url-path 之间的“/”不是 url-path 的一部分。
在这种情况下，“？”是 url-path 的一部分
...取决于所使用的方案，以及它的解释方式。
另请注意，根据规范，省略“/url-path”是完全有效的——注意“/”已明确包含在这种情况下。
因此，“foo.com?bar”是无效的，因为 url-path 之前没有“/”。
【讨论】：
在研究此问题后发现的更多信息添加到已接受的答案中：
https://www.rfc-editor.org/rfc/rfc2396
权限组件以双斜杠“//”开头，并以下一个斜杠“/”、问号“?”或 URI 结尾终止。在权限组件中，保留字符“;”、“:”、“@”、“?”和“/”
基于此声明，问号应指示权限组件的结尾，带或不带斜线。
https://www.rfc-editor.org/rfc/rfc1738（标签被替换）
{path} 是可选的，{searchpart} 及其前面的“?”也是如此。如果 {path} 和 {searchpart} 都不存在，“/”也可以省略。
但是，此语句表示，只有在未预设路径和搜索部分时，才能省略尾部斜杠。
在现实世界中，我以前可以在查询值之前省略尾部斜杠，但最近发现了一种情况。如果您有类似 http://my.domain.com?do=something 的查询，并且您在 Internet Explorer 中查看 html 页面，则该链接已被 IE固定。如果您随后单击“文件”、“发送”、“通过电子邮件发送页面...”，则会将链接添加到格式无效的电子邮件中。问题因查询值的内容而异，但我们能够创建无效的 URL。
总而言之，它应该工作，但在极端情况下会失败。
【讨论】：
假设这一点是不安全的。 Web 服务器和自包含 Web 应用程序通常会检查请求中提供的 URL，但不能保证它们会将 /abc 视为等于 /abc/。 Web 服务器和独立的 Web 应用程序可以使用从 URL 收集的信息为所欲为，这不一定是您所期望的。您将必须找出所讨论的特定 URL 的约定。
当然，请注意，大多数 Web 服务器和 Web 应用程序框架都努力接受各种输入并适当地处理它们。因此，在大多数情况下，Web 服务器或自包含 Web 应用程序会将 /abc 视为等于 /abc/。但是请记住，因为服务器可以对路径做任何它喜欢做的事情，这只是一个普通的观察，可能有很多例外。
【讨论】：
可以在两者之间使用查询字符串，下面也是示例
/rest/mainfolder/subfolder?jsonFormat=stream&/value1/value2
【讨论】：