【问题标题】:Parse HTML as PHP将 HTML 解析为 PHP
【发布时间】:2011-11-03 03:44:18
【问题描述】:

如果我们将 Apache Web 服务器设置为将 Apache 配置为将 所有 HTML 作为 PHP 处理,是否存在任何安全/性能问题?我特意指的是:

AddType application/x-httpd-php .php .php3 .php4 .html

我需要在一些 HTML 文件中添加一些 PHP 逻辑;理想情况下,我不必更改文件名,例如page.htmlpage.php(以保持 page.html 的页面排名等)。

这与以下问题有关:httpd AddType directive

修改: 从下面现有的答案/ cmets 来看,社区似乎建议使用重定向或仅针对特定的 HTML 文件。限制是我正在重新设计一个现有网站(400 多个 HTML 页面;每个页面都使用某种 Dreamweaver 模板,该模板从不同文件中提取页眉和页脚)。我希望完全回避 Dreamweaver 进入非专有领域。所以,我有两个选择:

  1. 使用Server Side Includes (SSI) to pull in the header and footer。这将导致我的所有 HTML 文件都使用 SSI 进行修饰。
  2. 添加一些 PHP sn-p 以包含页眉和页脚。对于这个选择,我必须确保文件名保持不变。

【问题讨论】:

  • 您是否考虑过改用 URL 重写?
  • 不要忘记它是可读的,如果你不小心重新配置了ie。忘记这个
  • Oli 有一个很好的观点。重写将是一个非常安全(更不用说简单)的解决方案。
  • 纯 html 文件会有一些额外的解析开销,但否则应该没有任何区别......除非其中一些 HTML 页面包含 PHP 代码作为示例,在“不要执行”类型的情况。现在 .html 文件被解析/执行为 php 脚本,该示例代码也将被执行。

标签: php html apache configuration apache2


【解决方案1】:

服务器确定它需要通过 PHP 解释器传递的文件越多,涉及的开销就越大,但我认为这是不言而喻的。如果您的网站没有任何带有纯 HTML 的页面,那么您已经支付了所有可能支付的性能损失 - 将 HTML 添加到列表中在这种情况下与简单地重命名所有页面没有什么不同扩展名为 .php 的文件。

如果您确实拥有纯 HTML 页面,则真正的性能损失会出现 - 服务器会在不需要时将这些页面不必要地传递给 PHP 进行解释。但即便如此,它也并不引人注目——那些 HTML 页面不需要 PHP 解释器,因此除了确定它不需要做任何事情之外,它不会做任何事情。这是有代价的,但并不重要。

现在,如果我们在这里谈论高容量,那么每一点性能都很重要,这不是一个切实可行的解决方案。但是,对于中低容量站点,性能损失为零。

如果这是一次性更改并且受影响的文件数量有限,那么使用FilesMatch 指令可能更保守。

<FilesMatch "^(file_one|file_two|file_three)\.html$">
  AddType application/x-httpd-php .html
</FilesMatch>

【讨论】:

  • 我看到你也添加了FileMatch ;) 还有+1,因为我们都知道谁真正给了你-1,不是吗?如果你愿意,可以回报。
  • 我确实回报了这个人情,但我不确定是谁在否决这些事实答案。我认为这里的任何答案都不是明显错误的,甚至是不明智的——它们都应该被投票或不投票。嗯。 :)
【解决方案2】:

我不同意 Tuga。我认为您不应该对所有文件进行此更改。每当您处理安全问题时,您都应该尝试控制环境。只为一个文件做可能是最安全的。你可以做类似的事情

<FilesMatch "^file_name\.html$">
AddType application/x-httpd-php .html
</FilesMatch>

这只会匹配 file_name.html 并将其处理为 .php 这样做比将 ALL .html 文件视为 php 更安全。

【讨论】:

    猜你喜欢
    • 2013-11-15
    • 2011-09-08
    • 1970-01-01
    • 2019-10-06
    • 2014-02-17
    • 2011-09-11
    • 2012-05-09
    • 2021-09-18
    相关资源
    最近更新 更多