|
Since the advent of HTTP/1.1 and the required Host header, shared hosting has become very popular. Without this header, there is no direct way for a web client to identify the domain. It makes a TCP/IP connection to the host identified by the domain, and that's where it sends its reqquest, which can be as simple as the following:
Toggle Code View GET /path/to/script.php HTTP/1.0 - GET /path/to/script.php HTTP/1.0
Notice that the URL presented in the request does not include the domain name. This is because it is unnecessary under the assumption that only one domain is served by a particular server. With HTTP/1.1, Host becomes a required header, so a simple request must be expressed as follows: Toggle Code View GET /path/to/script.php HTTP/1.1 Host: example.org - GET /path/to/script.php HTTP/1.1
- Host: example.org
With this format, a single web server can server many domains, because the client must identify the domain. As a result, a hosting company can host many domains on a single server, and it is not necessary to have a separate public IP for each domain. This yields much more inexpensive hosting and has spurred a tremendous growth in the web itself. Of course, this has been a driving force behind early PHP adoption as well. The downside to shared hosting is that it incurs some security risks that do not exist in a dedicated server environment. Some of these risks are mitigated by PHP's safe_mode directive, but it doesn't address the root cause of most security risks, and a solid understanding of these risks is necessary to appreciate what safe_mode does and doesn't do. Because of this, I begin by introducing some of the unique risks associated with shared hosting.
|
