Editing Virtual hosting (section)

==Name-based==
Name-based virtual hosts use multiple host names for the same [[IP address]].

A technical prerequisite needed for name-based virtual hosts is a web browser with [[HTTP]]/1.1 support (commonplace today) to include the target hostname in the request. This allows a server hosting multiple sites behind one IP address to deliver the correct site's content. More specifically it means setting the {{mono|Host}} [[List of HTTP headers|HTTP header]], which is mandatory in HTTP/1.1.<ref>{{cite journal
|url=http://tools.ietf.org/html/rfc7230#section-5.4
|title=Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
|publisher=[[IETF]]
|date=June 2014
|access-date=2014-07-24
|last1=Fielding
|first1=Roy T.
|last2=Reschke
|first2=Julian
|editor-first1=R.
|editor-first2=J.
|editor-last1=Fielding
|editor-last2=Reschke
|doi=10.17487/RFC7230
|doi-access=free
|url-access=subscription
}}
</ref>

For instance, a server could be receiving requests for two domains, {{mono|www.example.com}} and {{mono|www.example.net}}, both of which [[Domain Name System|resolve]] to the same IP address.  For {{mono|www.example.com}}, the server would send the [[HTML|HTML file]] from the directory {{mono|/var/www/user/Joe/site/}}, while requests for {{mono|www.example.net}} would make the server serve pages from {{mono|/var/www/user/Mary/site/}}. Equally two subdomains of the same domain may be hosted together. For instance, a blog server may host both blog1.example.com and blog2.example.com.

The biggest issue with name-based virtual hosting is that it is difficult to host multiple secure websites running [[transport layer security|SSL/TLS]]. Because the SSL/TLS [[Handshake (computing)|handshake]] takes place before the expected hostname is sent to the server, the server doesn't know which certificate to present in the handshake. It is possible for a single certificate to cover multiple names either through the "subjectaltname" field or through wildcards but the practical application of this approach is limited by administrative considerations and by the matching rules for wildcards. There is an extension to TLS called [[Server Name Indication]], that presents the name at the start of the handshake to circumvent that issue, except for some older clients (in particular [[Internet Explorer]] on [[Windows XP]] or older [[Android (operating system)|Android]] versions) which do not implement [[Server Name Indication|SNI]].

Furthermore, if the [[Domain Name System]] (DNS) is not properly functioning, it is difficult to access a virtually-hosted website even if the IP address is known. If the user tries to fall back to using the IP address to contact the system, as in {{mono|<nowiki>http://10.23.45.67/</nowiki>}}, the web browser will send the IP address as the host name. Since the web server relies on the web browser client telling it what server name (vhost) to use, the server will respond with a default website—often not the site the user expects.

A workaround in this case is to add the IP address and host name to the client system's [[hosts file]]. Accessing the server with the domain name should work again. Users should be careful when doing this, however, as any changes to the true mapping between host name and IP address will be overridden by the local setting. This workaround is not really useful for an average web user, but may be of some use to a site administrator while fixing DNS records.