像 /index.php/seo_path 这样的 URI 有多可靠
我注意到，有时（特别是在 mod_rewrite 不可用的情况下）会使用此路径方案：
http://host/path/index.php/clean_url_here
--------------------------^
这似乎可以工作，至少在 Apache 中，其中调用 index.php ，并且可以通过 $_SERVER['PATH_INFO'] 查询 /clean_url_here 部分。 PHP 甚至某种广告此功能。另外，例如，CodeIgniter 框架使用此技术作为其 URL 的默认技术。
问题：该技术的可靠性如何？是否存在 Apache 不调用 index.php 但尝试解析路径的情况？ lighttpd、nginx、IIS、AOLServer 怎么样？
ServerFault 问题？ 我认为这与在 PHP 代码中使用此功能有更多关系。所以我在这里问。
附录：根据 VolkerK 的建议，这个问题的合理扩展是：程序员如何影响 $_SERVER['PATH_INFO'] 在各种服务器类型上的存在？
I noticed, that sometimes (especially where mod_rewrite is not available) this path scheme is used:
http://host/path/index.php/clean_url_here
--------------------------^
This seems to work, at least in Apache, where index.php is called, and one can query the /clean_url_here part via $_SERVER['PATH_INFO']. PHP even kind of advertises this feature. Also, e.g., the CodeIgniter framework uses this technique as default for their URLs.
The question: How reliable is the technique? Are there situations, where Apache doesn't call index.php but tries to resolve the path? What about lighttpd, nginx, IIS, AOLServer?
A ServerFault question? I think it's got more to do with using this feature inside PHP code. Therefore I ask here.
Addendum: As suggested by VolkerK, a reasonable extension to this question is: How can a programmer influence the existence of $_SERVER['PATH_INFO'] on various server types?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据我的经验，我想说
PATH_INFO通常在正常的 Web 托管环境和服务器设置中可用 - 甚至在 IIS 上 - 但在极少数情况下，它不是可用的。当构建一个可以在尽可能多的平台上部署的应用程序时，我不会在硬编码级别上信任 path_info 。只要有可能，我都会尝试构建一个包装函数
build_url()，根据配置设置，它使用www.example.com/index.php?clean_url=clean_url_herewww.example.com/index.php/clean_urlwww.example.com/clean_url并在应用程序发出的所有 URL 中使用它。
From my experience I'd say
PATH_INFOis usually available in normal web hosting environments and server setups - even on IIS - but on rare occasions, it is not. When building an application that is supposed to be deployable on as many platforms as possible, I would not trust path_info on a hard-coded level.Whenever I can, I try to build a wrapper function
build_url()that, depending on a configuration setting, uses eitherwww.example.com/index.php?clean_url=clean_url_herewww.example.com/index.php/clean_urlwww.example.com/clean_urland use that in all URLs the application emits.
可能存在无法识别此 URL 格式的简单脚本（例如自动链接）。从而减少创建指向您内容的链接的机会。
由于本地开发的正则表达式模式对于这些任务很常见，因此失败的可能性是相当真实的。
从技术上讲，这些 URL 没有问题。就搜索引擎优化而言，它们“不太完美”。
There might be naive scripts (auto-linking for example) that do not recognize this URL's format. Thereby decreasing the chance that links to your content will be created.
Since home-grown regular expression patterns are common for these tasks, the chance of failure is quite real.
Technically, those URLs are fine. SEO-wise, they are 'less perfect'.
我认为这个问题同样适合 stackoverflow 和 serverfault。例如，作为开发人员，我只能告诉您 pathinfo 与任何用户输入一样值得信赖（这意味着它几乎可以包含任何内容），并且您的脚本可能会或可能不会收到它，具体取决于网络服务器版本和配置：
Apache：AcceptPathInfo
IIS：例如 AllowPathInfoForScriptMappings 等
等等...
但是服务器管理员可能可以告诉您“在现实世界中”可以期待哪些设置以及为什么首选这些设置。
所以问题就变成了：你（或预期的用户群）对服务器配置有多大影响。
I think this a question which is equally suited for stackoverflow and serverfault. E.g. I as a developer can only tell you that pathinfo is as trustworthy as any user-input (which means it can contain virtually anything) and your script may or may not receive it depending on the webserver version and configuration:
Apache: AcceptPathInfo
IIS: e.g. AllowPathInfoForScriptMappings and others
and so on and on...
But server admins possibly can tell you which settings you can expect "in the real world" and why those settings are preferred.
So the question becomes: How much influence do you (or the expected userbase) have on the server configuration.
需要启用 AcceptPathInfo为了让这个工作。
AcceptPathInfo needs to be enabled in order to have this working.