Disadvantages of Name Based Virtual Hosts

They do not support properly with secured websites (HTTPS). All name-based virtual hosts using the IP address must share the same digital certificate. This is because SSL / TLS handshake takes place before the host name is sent to the server. This type of server does not know what the connection is made to use encryption keys. TLS protocol, part of an extension to RFC 3546 - Transport Layer Security Extensions (TLS), as part of the handshake for the requested host name specifies a way to provide the client, but still is not widely applied. Some shared hosting providers in order to set up HTTPS properly for their customer; they are required to obtain unique IP. If the domain name system is bad, it's hard to use a name based on the fact - website hosting. Typically, in this case, the user can to fall back to IP addresses using the system contact http://192.0.2.0/ (for example invalid IP only). However, the Web browser knows the host name of the server but it does not send but a name-based virtual host requires it. In this case, the default Web host for that IP address is sent back to the browser. Therefore most hosts like to use an alternative method such as http://192.0.2.0/ ~ virtualhostname to provide access to such cases.

Those browsers that do not send requests as part of the host name will not work with. The old HTTP/1.0 protocol HTTP/1.1 browsers that have retrofitted the host field are true for facilities. ("Host" header that various DNS names sharing one IP address was optional in HTTP/1.0 different between. It is mandatory in HTTP/1.1, RFC 2616 as released in 1999). Since nearly every web browser that is currently used this type of support HTTP/1.1 protocol and virtual hosting, this is not a real issue. Improperly configured file permissions with shared file systems might give other (compromised) users or processes system-wide access to these files, such as credential files for database access or modification of existing files.