URL的域名部分不区分大小写，因为DNS忽略大小写: http://en.example.org/和HTTP://EN.EXAMPLE。ORG/两者都打开同一页。

路径用于指定或查找所请求的资源。它是区分大小写的，尽管它可能被某些服务器视为不区分大小写，特别是那些基于Microsoft Windows的服务器。

如果服务器区分大小写，并且http://en.example.org/wiki/URL是正确的，那么http://en.example.org/WIKI/URL或http://en.example.org/wiki/url将显示一个HTTP 404错误页面，除非这些url指向有效资源本身。

考虑以下几点:

https://www.example.com/createuser.php?name=Paul%20McCartney

在这个假设的示例中，HTML表单(使用GET方法)将“name”参数发送给创建新用户帐户的PHP脚本。

我在这个例子中要强调的一点是，这个GET参数需要区分大小写，以保留“McCartney”的大写字母(或者，作为另一个例子，保留“Walter d’isney”，因为还有其他方法可以打破通常的大写字母规则)。

正是这样的情况指导了W3C的建议，即方案和主机不区分大小写，但之后的所有内容都可能区分大小写——这取决于服务器。通过标准强制不区分大小写将使上面的示例无法保留作为GET查询参数传递的用户输入的大小写。

但我想说的是，尽管这是法律条文中对此类案件的规定，但法律的精神是，在与案件无关的情况下，不区分案件。然而，这些标准并不能告诉你什么情况下大小写无关紧要，因为，就像我给出的例子一样，这是一个与上下文相关的东西。

(例如，帐户用户名最好不区分大小写，因为“User123”和“User123”是不同的帐户，可能会令人混淆，即使他们的真实姓名，如上所示，最好是左区分大小写。)

有时是相关的，大多数时候不是。但这必须由服务器/ web开发人员来决定这些事情——不能由标准规定——因为只有在这个级别上才能知道上下文。

方案和主机是不区分大小写的(这显示了标准对不区分大小写的偏好，在这里它可以被普遍规定)。其余的由您自己决定，因为您更好地理解了上下文。但是，正如已经讨论过的，根据法律的精神，您可能应该默认不区分大小写，除非您有很好的理由不这样做。

请看这里的规格: 2.7.3节 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p1-messaging-25#page-19

scheme和host不区分大小写，通常以小写形式提供;所有其他组件以区分大小写的方式进行比较 的方式。

老问题，但我在这里绊了一下，所以为什么不尝试一下呢，因为这个问题寻求的是不同的观点，而不是一个确定的答案。

w3c可能有它的建议-我很关心-但想要重新考虑，因为问题在这里。

为什么w3c认为域名是不区分大小写的，并且在后面留下不区分大小写的内容?

我认为基本原理是URL的域部分是由用户手动输入的。 超文本之后的所有内容都将由机器(浏览器和后面的服务器)解析。

机器可以比人类更好地处理不区分大小写的问题(不是技术上的:))。

但问题是，仅仅因为机器可以处理，就应该这样做吗?

我的意思是命名和访问位于hereIsTheResource和hereIsTheResource的资源的好处是什么?

横向图比驼色图更难读，驼色图更容易读。 人类可读(包括技术类)

以下是我的观点:-

资源路径位于编程结构的中间位置，有时靠近浏览器后面的终端用户。

你的URL(不包括域名)应该不区分大小写，如果你的用户希望触摸它或键入它等等。在开发应用程序时，应该尽量避免让用户键入路径。

你的URL(不包括域名)应该区分大小写，如果你的用户从来不会手动输入它。

结论

Path应该区分大小写。我的观点倾向于区分大小写。

取决于主机操作系统。托管在Windows上的站点往往不区分大小写，因为底层文件系统不区分大小写。托管在Unix类型系统上的站点往往是区分大小写的，因为它们的底层文件系统通常是区分大小写的。URL的主机名部分总是不区分大小写的，路径的其余部分是不同的。

根据W3的“HTML和url”，它们应该:

可能有url，或者url的一部分，大小写不重要，但是 识别这些可能并不容易。用户应该始终考虑到这一点 url区分大小写。