In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

In order to make embedding PHP truly simple for all of our developers we developed the PHPEmbed library which is just a more accessible and simplified API built on top of the PHP SAPI. The library is so useful, we decided to share it with the world. Check it out for yourself at http://developers.facebook.com/phpembed/

The library (currently in release 20070924) can be grabbed either directly from their download link or via the public svn repository they've set up. There's also some documentation and help for it in the form of a developer's group and the manual (PDF/HTML).

The issue is actually a windows bug. No matter if I give or not the "b" flag to fopen, the write operations are not binary safe. It seems to be a known issue as many projects use the same trick.

The problem comes up when PHP forces the binary mode in SAPI and CLI, making the binary writes to a file non-binary safe no matter what. Pierre is also asking for help from anyone out there with any information/bug reports/references about this issue that would yield something useful.

He talks about a history of how things go to where they are, starting back with regular CGI scripts, moving up through using server-based APIs, and finally to FastcGI, a method for overcoming a lot of the limitations of its predecessors.

With that look back, he turns his attention around and looks to the current situation within PHP. He talks about the sudden appearance fastcgi made in PHP's SAPIs, but that the implementation wasn't true. He suggests that the reasoning behind this "fake" implementation was for the sake of speed. He also notes, however, it's his opinion that true FastCGI support in PHP will be a requirement for future large-scale applications.