为什么我们不使用这样的 URL 格式？
我正在修改项目的 URL 格式。我们的搜索 URL 的基本格式是这样的：-
www.projectname/module/search/<search keyword>/<exam filter>/<subject filter>/... other params ...
在没有搜索关键字和考试过滤器的情况下进行搜索时，URL 将是：-
www.projectname/module/search///<subject filter>/... other params ...
我的问题是为什么我们看不到带有背对背斜杠的 URL（www.projectname 之后有 3 个斜杠） /模块/搜索）？请注意，我不再在项目中使用 .htaccess 重写规则。该 URL 功能完美。那么，我应该使用这种格式吗？
有关我们为什么选择这种格式的更多详细信息，请查看我的其他问题：- 建议最佳网址样式
I am reworking on the URL formats of my project. The basic format of our search URLs is this:-
www.projectname/module/search/<search keyword>/<exam filter>/<subject filter>/... other params ...
On searching with no search keyword and exam filter, the URL will be :-
www.projectname/module/search///<subject filter>/... other params ...
My question is why don't we see such URLs with back to back slashes (3 slashes after www.projectname/module/search)? Please note that I am not using .htaccess rewrite rules in my project anymore. This URL works perfect functionally. So, should I use this format?
For more details on why we chose this format, please check my other question:-
Suggest best URL style
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
出于兼容性和安全原因，Web 服务器通常会在应用程序看到请求之前删除多个斜杠。当提供纯文件时，通常允许路径段之间任意数量的斜杠充当一个斜杠。
空白 URL 路径段在 URL 中并非无效，但通常会避免使用，因为带有空白段的相对 URL 可能会意外解析。例如，在
/module/search中，指向//subject/param的链接不是相对于文件的，而是指向服务器subject的链接> 路径为/param。您是否可以从原始 URL 中看到多个斜杠序列取决于您的服务器和应用程序框架。例如，在 CGI（以及基于它的其他网关标准）中，通常用于实现路由的 PATH_INFO 变量通常会省略多个斜杠。但在 Apache 上，有一个非标准环境变量
REQUEST_URI，它提供了请求的原始形式，而没有像PATH_INFO那样省略斜杠或进行任何 % 转义。因此，如果您想允许空路径段，您可以这样做，但这会减少您的部署选项。除了空字符串之外，还有其他字符串也不能构成良好的路径段。许多服务器默认阻止使用编码的
/(%2F)、\(%5C) 或空字节 (%00)。所以你不能将任何旧字符串放入段中；必须对其进行处理以删除一些字符（通常“slug”化以删除除字母和数字之外的所有字符）。当您执行此操作时，您也可以将空字符串替换为_。Web servers will typically remove multiple slashes before the application gets to see the request,for a mix of compatibility and security reasons. When serving plain files, it is usual to allow any number of slashes between path segments to behave as one slash.
Blank URL path segments are not invalid in URLs but they are typically avoided because relative URLs with blank segments may parse unexpectedly. For example in
/module/search, a link to//subject/paramis not relative to the file, but a link to the serversubjectwith path/param.Whether you can see the multiple-slash sequences from the original URL depends on your server and application framework. In CGI, for example (and other gateway standards based on it), the
PATH_INFOvariable that is typically used to implement routing will usually omit multiple slashes. But on Apache there is a non-standard environment variableREQUEST_URIwhich gives the original form of the request without having elided slashes or done any %-unescaping likePATH_INFOdoes. So if you want to allow empty path segments, you can, but it'll cut down on your deployment options.There are other strings than the empty string that don't make good path segments either. Using an encoded
/(%2F),\(%5C) or null byte (%00) is blocked by default by many servers. So you can't put any old string in a segment; it'll have to be processed to remove some characters (often ‘slug’-ified to remove all but letters and numbers). Whilst you are doing this you may as well replace the empty string with_.可能是因为没有明确定义是否应该忽略额外的 / 。
例如： http://news.bbc.co.uk/sport 和 http://news.bbc.co.uk//////// ///sport 在 Firefox 和 Chrome 中都显示相同的页面。服务器将这两个 URL 视为同一事物，而您的服务器显然不会。
我不确定这种行为是否在某处定义，但它似乎确实有意义（至少对于 BBC 网站来说 - 如果我输入一个额外的 /，它就会按照我的意思做。）
Probably because it's not clearly defined whether or not the extra / should be ignored or not.
For instance: http://news.bbc.co.uk/sport and http://news.bbc.co.uk//////////sport both display the same page in Firefox and Chrome. The server is treating the two urls as the same thing, whereas your server obviously does not.
I'm not sure whether this behaviour is defined somewhere or not, but it does seem to make sense (at least for the BBC website - if I type an extra /, it does what I meant it to do.)