URI 是不是不区分大小写？

Posted 2023-02-22

【中文标题】URI 是不是不区分大小写？

【英文标题】：Are URIs case-insensitive?URI 是否不区分大小写？

【发布时间】：2013-03-16 12:30:47

【问题描述】：

在比较两个 URI 以确定它们是否匹配时，客户端 应该对整个字节进行区分大小写的逐个字节比较 URI，但以下例外：

我在Http Rfc 中阅读了上面的句子我认为Url 不区分大小写，但我不明白这意味着什么 ?

【问题讨论】：

从技术上讲，URI 和 URL 不是等价的术语，所以这不是这个非常相似的问题的重复：***.com/questions/7996919/…

这能回答你的问题吗？ Should URL be case sensitive?

【参考方案1】：

RFC 3986 状态：

方案和主机不区分大小写，因此应标准化为小写。例如，URI <HTTP://www.EXAMPLE.com/> 等价于 <http://www.example.com/>。 除非方案另有明确定义，否则假定其他通用语法组件区分大小写

RFC 2616 为HTTP 方案定义了以下比较规则：

在比较两个 URI 以确定它们是否匹配时，客户端应使用区分大小写的字节对整个 URI 进行逐个字节比较，但以下情况除外：

但是，RFC 7230 通过声明进一步锁定它：

方案和主机不区分大小写，通常以小写形式提供； 所有其他组件都以区分大小写的方式进行比较。

这些规则通常适用于客户端比较。没有专门针对服务器端比较的规则。一旦服务器将 URI 分解为其组件，它应该根据相同的规则处理它们，但我认为 RFC 中没有强制执行。一些 Web 服务器，如 Apache，确实遵循规则。 IIS 没有，因为它与 Windows 的不区分大小写的文件系统兼容。

【讨论】：

所以我想问题变成了提供良好用户体验的问题。您的站点或服务是否应该区分大小写？我想这不是 SO 的问题，而是 OpinionOverflow.com 的问题

【参考方案2】：

实际上它取决于网络服务器。

IIS 不区分大小写。

Apache 是。

我怀疑有关 IIS 的决定源于 Windows 文件系统不区分大小写这一事实。

IIS 仍然符合规范的该部分，因为应该是建议，而不是要求。

【讨论】：

应该是建议，而不是要求。它仍然符合规范。

SHOULD 被 RFC 2616 允许，但不再被 RFC 7230 允许。

@RemyLebeau：RFC 7230 的状态是 PROPOSED STANDARD，这比 RFC 2616 的状态 DRAFT STANDARD 不太明确 :-) 我敢打赌，如果它开始起作用，大量构建在 IIS 上的应用程序将会中断区分大小写。在某些时候，IIS 可能带有区分大小写的模式，但我敢打赌，它可以关闭相当长的一段时间。请注意，方案和主机将保持不区分大小写。

这个答案并不完整——结果取决于底层文件系统，而不是网络服务器。 Windows 上的 Apache（使用 NTFS/FAT）不区分大小写； Linux 上的 apache (extx) 是。

@Beel，不，这取决于服务器的配置/行为。由于底层文件系统的大小写敏感性，URL /myPath 和 /mypath 是否最终被 Web 服务器解析为同一个文件是另一回事。 URL 甚至可能与服务器上的文件路径不对应，例如如果它们是 API 端点；或者即使它们这样做并且文件系统不区分大小写，它们也可能由 Web 服务器以某种方式进行翻译，从而导致结果不同，例如/myPath → C:\webroot\myfile1 和 /mypath → C:\webroot\myfile2。

【参考方案3】：

URI 的主机部分不区分大小写：

http://***.com
http://***.com

以上任何一项都可以让您访问此站点。

在主机部分之后的 URI 的其余部分可以区分大小写。这取决于服务器。

【讨论】：

当然，两个 URI 都会将您带到同一个网络服务器，但不是由网络服务器来决定如何处理 URI 吗？可以想象，它可以针对不同的情况做不同的事情。

@Colin'tHart - 您是正确的，网络服务器可能会根据域的情况采取不同的行动。但一般来说，网络服务器不会这样做。如果你知道有一个，我很想听听。

"这取决于服务器。" - 严格来说，它取决于运行在网络服务器上的应用程序。但是URL-path portion of the URL is defined as case-sensitive in the RFCs，所以任何处理URL 的系统（例如Google 等）都必须将/my-url 和/MY-URL 视为两个不同的URL。如果这两个 URL 返回相同的内容（即应用程序不区分大小写地处理 URL，并且没有规范化请求），那么您可能会遇到内容重复的问题。

【参考方案4】：

正如 Remy Lebeau 在回答中提到的，规则是为客户端设置的。实际上，这意味着 客户端软件 不应该尝试对 URI 的所有部分进行任意大小写修改，除非有明确说明的部分。因此，当浏览器例如在页面锚点中看到相对 URL，在检查它是否已缓存在其缓存中之前不应将其转换为小写；它也不应该使用小写的 URI 来发布到服务器。此外，它不应该决定两个不同的 URI 仅指向相同的资源（因此可能错误地跳过事务并返回缓存的结果）。

这意味着客户端不应假设服务器如何处理 URI。它确实需要服务器以不区分大小写的方式处理 一些 部分：例如，方案和主机。但除此之外，由服务器决定两个大小写不同的 URI 是否指向同一个资源。标准在这方面对服务器没有任何限制，除了直接规定之外，没有“服务器应该”或“服务器不应该”。如果服务器决定它的 URI 不区分大小写，那绝对没问题。如果它们区分大小写，那也没关系。

【参考方案5】：

URL 是否区分大小写也取决于网络服务器。例如，Microsoft IIS 服务器不将 URL 视为区分大小写。

以下 URL（托管在 Microsoft IIS 服务器上）都被视为等效：

http://www.microsoft.com/default.aspx http://www.microsoft.com/Default.aspx

但是，Apache 服务器确实将 URL 视为区分大小写，这被归类为两种不同的资源：

http://httpd.apache.org/index.html http://httpd.apache.org/Index.html

从技术上讲，Apache 在这里正确地遵循了标准，而微软则违反了规范……哦，好吧——“旧习惯很难改掉，”他们说！

【参考方案6】：

对于基于文件的 URI，区分大小写更多地取决于底层文件系统，而不是 Web 服务器。 Apache 很乐意在 Windows（FAT、NTFS）和 mac (HFS) 上为 INDEX.html 返回 index.html，但对于通常在 Linux 中使用的那些区分大小写的文件系统（extx 等）则不会。