我注意到了
HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK
和
http://stackoverflow.com/questions/ask
两者都工作正常 - 实际上前一个转换为小写。
我认为这对用户来说很有意义。
如果我查看Google，那么此网址可以正常使用：
http://www.google.com/intl/en/about/corporate/index.html
但这个“关于”的人不起作用：
http://www.google.com/intl/en/ABOUT/corporate/index.html
URL应该区分大小写吗？
根据W3的“HTML and URLs”，他们应该：
可能存在URL或URL的一部分，其中大小写无关紧要，但识别这些可能并不容易。用户应始终认为URL区分大小写。
URL字符被转换为十六进制代码（如果您注意到URL中的空格显示为％20等），并且由于大写和小写字母具有不同的十六进制值，因此URL绝对区分大小写非常合理。然而问题的精神似乎应该是标准，我说不，但他们是。如果开发人员/提供商希望无论最终用户如何工作，都可以在代码中对此进行说明。
我认为这个以及关于规范所说或未说的内容的许多答案都忽略了问题的重点。他们应该区分大小写吗？真的是这个问题。从用户的角度来看，区分大小写是一个痛点，并非所有知识都有所不同。 URI是否应该是的问题取决于问题的背景。为了技术灵活性，是的，它们应该是。对于可用性，不，它们不应该。
URL在客户端和服务器之间是保留大小写的。但由于几个原因，部分URL可能会也可能不区分大小写，具体取决于服务器。
URL的以下粗体部分可能区分大小写，具体取决于站点和/或服务器配置。
http：// www。 example.com /abc/def.ghi?jkl=mno#pqr
user @ example.com
URL中的区分大小写可以有多种用途。主要是：
作为开发人员，我相信上述内容通常可以用更好的方式处理，但我也理解有些情况可能不允许这样做。
例如，假设现有产品需要在“GET”URL中放置大量数据，但它必须与所有主要服务器，浏览器和缓存/代理机制的最大URL长度兼容。为了适应中等长度的命令字符串（对于一些旧版浏览器而言，不到1,024个字符），您需要使用每个唯一的URL安全字符（基本上是base64url编码）。
URL是否应区分大小写是值得商榷的。我个人认为它们不应该是，为简单起见（虽然它可能会创建更长的URL，但我们有百分之百的转义来轻松处理我们必须确保保留确切字符的情况，并且有一些方法可以在URL中传输除右边的数据） 。
许多人似乎同意这样的事实，即为许多流行的网站和服务明确启用了不区分大小写的URL，以提高可用性。最突出的例子是电子邮件地址的用户名部分。大多数电子邮件提供商将忽略大小写，有时甚至忽略点和其他符号（例如“[email protected]”与“[email protected]”相同）。根据规范，即使电子邮件用户名默认区分大小写。
然而，事实是，尽管我或其他人可能想要，但这是目前的工作状态。尽管最终全球过渡到不区分大小写的URL标准当然是可能的，但由于案例敏感性目前在网络上广泛用于各种目的，因此可能需要相当长的时间。
就最佳实践而言，作为用户，您可以在大多数情况下合理地坚持使用小写并期望工作正常。主要的例外是使用基于案例的编码的URL或具有直接文件系统等价物的文档路径。但是，这些复杂的URL通常是复制粘贴（或简单地单击）而不是手动键入。
作为Web开发人员，您应该考虑将URL保持为不区分大小写。尽管如上所述，根据具体情况，显然存在一些难以避免的情况。
问题是网址是否应区分大小写？
我认为在区分大小写的URL后面没有任何用处或良好做法。这很愚蠢，很糟糕，应该随时避免。
只是为了支持我的观点，当有人问什么URL时，你怎么能解释URL的大小写是什么？这是无稽之谈，不应该有人告诉你。
对于Linux服务器中托管的网站，URL区分大小写。 http://www.google.com/about和http://www.google.com/About将被重定向到不同的位置。在Windows Server中，URL不区分大小写，如命名FOLDER并将重定向到相同位置。
可以创建不区分大小写的URL
RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]
将Google.com..GOOGLE.com等直接发送到google.com
所有“不敏感”都是加粗的以便于阅读。
根据RFC 4343，域名不区分大小写。 URL的其余部分通过GET方法发送到服务器。这可能是区分大小写的。
以此页面为例，stackoverflow.com收到GET字符串/questions/7996919/should-url-be-case-sensitive，将HTML文档发送到您的浏览器。 Stackoverflow.com不区分大小写，因为它为/QUEStions/7996919/Should-url-be-case-sensitive产生相同的结果。
另一方面，除了标题的第一个字符外，维基百科区分大小写。网址https://en.wikipedia.org/wiki/Case_sensitivity和https://en.wikipedia.org/wiki/case_sensitivity导致相同的文章，但https://en.wikipedia.org/wiki/CASE_SENSITIVITY返回404。
取决于托管操作系统。由于底层文件系统不区分大小写，因此Windows上托管的站点往往不区分大小写。 Unix类型系统上托管的站点往往区分大小写，因为它们的底层文件系统通常区分大小写。 URL的主机名部分始终不区分大小写，它是路径的其余部分。
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本身指向有效资源。
我不喜欢碰到旧文章，但因为这是对这一特定问题的第一批回应之一，我觉得有必要澄清一些事情。
正如@Bhavin Shah回答的那样，url的域部分是不区分大小写的，所以
http://google.com
和
http://GOOGLE.COM
和
http://GoOgLe.CoM
是完全相同的，但域名部分之后的所有内容都被视为区分大小写。
所以...
http://GOOGLE.COM/ABOUT
和
http://GOOGLE.COM/about
是不同的。
注意：我说的是“技术上”而不是“字面上”在很多情况下，大多数情况下，服务器设置为处理这些项目相同，但是可以设置它们以便它们不会被处理相同。
不同的服务器处理不同的方式，在某些情况下，它们必须区分大小写。在许多情况下，查询字符串值是编码的（例如作为查询字符串值传递的Session Ids或Base64编码数据）这些项目的性质区分大小写，因此服务器在处理它们时必须区分大小写。
因此，为了回答这个问题，“应该”服务器在获取这些数据时会区分大小写，答案是“是的，绝对是”。
当然不是所有东西都需要区分大小写，但服务器应该知道它是什么以及如何处理这些情况。
@Hart Simha的评论基本上也说了同样的话。在我发布之前我错过了，所以我想在信用到期时给予信用。
请看这里的规范：第2.7.3节http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19
该方案和主机不区分大小写，通常以小写形式提供;所有其他组件都以区分大小写的方式进行比较。
URL应该不区分大小写，除非有充分的理由说明它们不应该是。
这不是强制性的（它不是RFC的任何部分），但它使URL的通信和存储更加可靠。
如果我在网站上有两个页面：
http://stackoverflow.com/ABOUT.html
和
http://stackoverflow.com/about.html
他们应该如何区别？也许有人写的是“喊叫风格”（大写） - 但从IA的角度来看，不应该通过改变URL的情况来区分。
而且，在Apache中很容易实现它 - 只需使用mod_Speling中的CheckSpelling On。
考虑以下：
https://www.example.com/createuser.php?name=Paul%20McCartney
在这个假设的示例中，HTML表单（使用GET方法）将“name”参数发送到创建新用户帐户的PHP脚本。
我在这个例子中提出的观点是，这个GET参数需要区分大小写以保持“McCartney”的大写（或者，作为另一个例子，保留“Walter d'Isney”，因为还有其他方法为了打破通常的大写规则的名称）。
像这样的情况指导W3C建议方案和主机不区分大小写，但之后的所有内容都可能区分大小写 - 并留给服务器。通过标准强制不区分大小写会使上面的示例无法保留作为GET查询参数传递的用户输入的情况。
但我要说的是，尽管这必然是适用于此类案件的法律条文，但法律的精神在于，如果案件无关紧要，则以不区分大小写的方式行事。但是，这些标准无法告诉你哪种情况无关紧要，因为就像我给出的例子一样，它是依赖于上下文的东西。
（例如，帐户用户名可能最好被强制为不区分大小写 - 因为“User123”和“user123”是不同的帐户可能会让人感到困惑 - 即使他们的真实姓名（如上所述）最好区分大小写。）
有时它是相关的，大部分时间都不是。但是必须由服务器/ Web开发人员来决定这些事情 - 并且不能通过标准规定 - 因为只有在那个级别才能知道上下文。
该方案和主机不区分大小写（它显示了标准对不区分大小写的偏好，它可以普遍规定）。剩下的由你来决定，因为你更了解情况。但是，正如已经讨论的那样，除非你有充分的理由不这样做，否则你可能应该在法律的精神下违反案例不敏感。
老问题，但我偶然发现，所以为什么不采取行动，因为问题是寻求各种观点，而不是一个明确的答案。
w3c可能有它的建议 - 我非常关心 - 但是想要重新思考，因为问题就在这里。
为什么w3c认为域名不区分大小写，之后不区分大小写？
我认为理由是URL的域部分是由用户手工输入的。超文本后的所有内容都将由机器（后面的浏览器和服务器）解析。
机器可以比人类更好地处理不区分大小写（不是技术类:)。
但问题只是因为机器可以处理它应该这样做吗？
我的意思是命名和访问位于hereIsTheResource和hereistheresource的资源有什么好处？
横向是非常难以理解的骆驼箱更易读。对人类可读（包括技术类）。
所以这是我的观点： -
资源路径落在编程结构中间的某个位置，有时接近浏览器后面的最终用户。
如果您的用户需要触摸它或键入它等，您的URL（不包括域名）应该不区分大小写。您应该将应用程序开发为AVOID，让用户尽可能地键入路径。
如果您的用户永远不会手动输入，您的URL（不包括域名）应区分大小写。
结论
路径应区分大小写。我的观点正在考虑区分大小写的路径。