dongpu3792
2014-10-08 12:43
浏览 76
已采纳

在生产中使用PHP内置服务器

I was recently curious about PHP 5.4's built-in webserver. On the surface it seems as though, while rather barebones, with enough work it could be possible to distribute PHP applications that traditionally depend on a separate web server, like WordPress, as standalone scripts that you could just run with php -S localhost:80 app.php (or, more likely, './wordpress.sh'). They might even ship with their own PHP interpreter that has all the features the application needs, which would obviate the need for targeting many different versions of the language.

It's re-inventing the wheel somewhat, but it would certainly increase portability and reduce complexity for the end user.

However, I saw the following on the documentation page:

This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.

This would obviously refer to issues like proper filesystem security and serving the correct HTTP headers, which can be worked through. However, is there more to it? Are there inherent security concerns and/or technical limitations with using PHP's built-in web server in a production environment that can't be worked around? If so, what are they?

图片转代码服务由CSDN问答提供 功能建议

我最近对PHP 5.4的内置网络服务器感到好奇。 从表面上看,虽然相当准系统,但有足够的工作,可以将传统上依赖于单独的Web服务器的PHP应用程序(如WordPress)作为独立脚本分发,您可以使用 php -S运行它们 localhost:80 app.php (或者更可能是'./ wordpress.sh')。 他们甚至可能附带自己的PHP解释器,它具有应用程序所需的所有功能,这样就无需针对许多不同版本的语言。

它正在重新发明轮子 ,但它肯定会增加可移植性并降低最终用户的复杂性。

但是,我在文档页面

此Web服务器旨在帮助开发应用程序。 它也可用于测试目的或在受控环境中运行的应用程序演示。 它不是一个功能齐全的Web服务器。 它不应该在公共网络上使用。

这显然会引起诸如正确的文件系统安全性和提供正确的HTTP头之类的问题,这些问题可以通过。 但是,还有更多吗? 在无法解决的生产环境中使用PHP的内置Web服务器是否存在固有的安全问题和/或技术限制? 如果是这样,他们是什么?

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 收藏
  • 邀请回答

4条回答 默认 最新

  • dsgtew3241 2014-10-08 19:15
    已采纳

    I can think of plenty of operational issues why you wouldn't want to do this:

    • Logging
    • Rewrites
    • Throttling
    • Efficiency (not tested, but I'm guessing Nginx is a lot faster than PHP's built-in non-optimized server)
    • Integration with anything else you have that extends Nginx, Apache, and IIS (things like New Relic)

    However, there is a solution where you get most of the benefit of running PHP with its built-in web server while getting most of the benefit of running a web server out front. That is, you could use a server like Nginx as a reverse proxy to PHP's built-in web server. In this situation, HTTP becomes a replacement for FastCGI, analogous to common usages of the built-in HTTP server in Node.js applications.

    Now, I can't speak to the specifics of the warning in the documentation as I am not one of the PHP authors. If it were me, I'd not run PHP alone for the reasons above, but I might consider running it behind a real web server like Nginx. For me though, setting up PHP with PHP-FPM and what not isn't that difficult, and I'll take that over guessing at the seaworthiness of a built-in server that is documented to be for testing only.

    评论
    解决 无用
    打赏 举报
查看更多回答(3条)

相关推荐 更多相似问题