The PHP engine interprets the PHP code and is perfectly capable of working with sockets, forming HTTP packets, etc. Why then do we need a separate Apache server, when the http serving duties could be embedded into the php application along with the page creation code?
3
In addition to Yannis’ answer, I want to add a few points.
The PHP engine can handle sockets so you could write a basic web server. You can also write a web server in Visual Basic 6 with the Winsock control – but it’s not the right tool for the job.
Apache is a hugely powerful web server. It makes no sense to reinvent the wheel, particularly for a non-commercial project with limited scope, when the PHP team can leverage the testing, research and development that went into building Apache.
The other thing you definitely need to consider is that PHP doesn’t support threads. There are workarounds (using shell_exec, for example), but you would be unable to write a multithreading server.
1
As of PHP 5.4 we don’t need a separate web server, the CLI SAPI provides one build in. It’s a fairly new addition to the language, and I wouldn’t use it on production:
This web server is designed for developmental purposes only, and should not be used in production.
The build in web server might not be ready for production (yet?), but it does prove that PHP is more than capable of working without a third party web server. As for building a web server in PHP, that’s also possible and a good example is nanoweb. The project appears to be dead, but you can still download its source and fool around with it.
3
Not just PHP but any language runtime used for web applications development. Actually all of them, including PHP as mentioned by Yannis Rizos, can handle http communication themselves and it is used for testing purposes. But it’s not used for production. The reasons are:
Configurability
The dedicated web servers support virtual hosts, URL rewriting, authentication, SSL and similar things that would have to be implemented in each an every web application runtime.
Having separate front-end web server and back-end application engine allows mixing and matching features provided by different implementations of each.
Uniform interface
A single computer only has one port 80, so only one process can be listening on it. But typical public web server runs multiple different webs and web applications often implemented in different languages. The only way to get them all run together on the same host is to have the web server in front of them that dispatches the request appropriately.
Reliability
Bugs in the web application can crash the engine or at least make the engine unresponsive. The web server can shield other visitors from such problems by multiplexing the requests over multiple instances of the back-end and restarting those instances when they exhibit problems. Apache normally preventively restarts it’s workers after 100 or so requests. Different front-ends can do things differently, but all are able to restart misbehaving back-end.
It would be hard to have multiple requests running at same time.
However PHP 5.5 will have coroutines which should make writing simple servers much more sensible. (if coroutines in PHP are same as coroutines in other systems).
There are quite a few pure Python web servers, and they work great.