[Httpd Wiki] Update of "NameBasedSSLVHostsWithSNI" by ChrisPepper

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "NameBasedSSLVHostsWithSNI" page has been changed by ChrisPepper.
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI?action=diff&rev1=8&rev2=9

--------------------------------------------------

  Before there is even an SSL handshake, Apache finds the best match for the IP address and TCP port the connection is established on (IP-based virtual hosting)
  
  If there is a NameVirtualHost directive that has the same literal arguments as this best-matching VirtualHost, Apache will instead
- consider ALL VirtualHost entires with identical arguments to the matched VirtualHost.  Otherwise, SNI processing has no selection to perform.
+ consider ALL VirtualHost entries with identical arguments to the matched VirtualHost.  Otherwise, SNI processing has no selection to perform.
  
- If the client sends a hostname along with it's TLS handshake request, Apache will compare this TLS hostname to the ServerName/ServerAlias of the candidate VirtualHost set determined in the preceding steps.
+ If the client sends a hostname along with its TLS handshake request, Apache will compare this TLS hostname to the ServerName/ServerAlias of the candidate VirtualHost set determined in the preceding steps.
  
- Whichever VirtualHost is selected on the preceding basis will have it's SSL configuration used to continue the handshake.  Notably, the contents of the certificates are not used in any comparison.
+ Whichever VirtualHost is selected on the preceding basis will have its SSL configuration used to continue the handshake.  Notably, the contents of the certificates are not used in any comparison.
  
- This process mimics the normal (albet misundersood) consecutive application of IP-based, then name-based, vhost matching algorithm used with HTTP, except that the input is the TLS data and not a HTTP header.
+ This process mimics the normal (albet misundersood) consecutive application of IP-based, then name-based, vhost matching algorithms used with HTTP, except that the input is the TLS data and not an HTTP header.