curl-sni: fix a few typos

Signed-off-by: Olivier Gayot <og@satcom1.com>

1 files changed, 11 insertions, 11 deletions

diff --git a/posts/curl-and-the-tls-sni-extension.rst b/posts/curl-and-the-tls-sni-extension.rst
index 1753dd5..dc03c2d 100644
--- a/posts/curl-and-the-tls-sni-extension.rst
+++ b/posts/curl-and-the-tls-sni-extension.rst
@@ -12,14 +12,14 @@ via HTTP and HTTPS.
 
 You own the NS domain *example.org* and it points to your machine.
 
-You are using virtualhosts to manage your different websites. In other words,
-the *Host* HTTP header is analysed by your webserver so it can make the
+You are using virtual hosts to manage your different websites. In other words,
+the *Host* HTTP header is analysed by your web server so it can make the
 decision of which website it is going to serve.
 
-However, these virtualhosts are not pointing to your machine yet. Only
+However, these virtual hosts are not pointing to your machine yet. Only
 *example.org* does.
 
-Here is an excerpt of a Nginx configuration using three virtualhosts:
+Here is an excerpt of a Nginx configuration using three virtual hosts:
 
 * example.org (it will be served by default because of the **default_server** directive),
 * vhost1.example.org,
@@ -87,7 +87,7 @@ Let's try that out with HTTP::
     default
 
 The default website is served because 172.31.99.217 does not match any
-virtualhost *server_name* directive::
+virtual host *server_name* directive::
 
     $ curl http://vhost1.example.org
     curl: (6) Could not resolve host: vhost1.example.org
@@ -143,21 +143,21 @@ Now let's see what happens if we use the HTTPS version::
     $ curl https://176.31.99.217
     curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217'
 
-The second command fails because the default webserver answered with its
+The second command fails because the default web server answered with its
 certificate, but it is not valid for *176.31.99.217*, only *example.org*.
 
 This is a normal behaviour. We can solve this issue by creating a certificate
 valid for *example.org* and *176.31.99.217* for example.
 
-But what about requesting our virtualhosts ? Well, pretty much the same happens
-as it did before (unless you didn't clear your */etc/hosts* file)::
+But what about requesting our virtual hosts ? Well, pretty much the same
+happens as it did before (unless you didn't clear your */etc/hosts* file)::
 
     $ curl https://vhost1.example.org
     curl: (6) Could not resolve host: vhost1.example.org
     $ curl https://vhost2.example.org
     curl: (6) Could not resolve host: vhost2.example.org
 
-The good news is: it will still work if you modify your */etc/hosts* file (huray)::
+The good news is: it will still work if you modify your */etc/hosts* file (hurray)::
 
     $ cat /etc/hosts
     127.0.0.1       localhost
@@ -183,9 +183,9 @@ website to serve. Nevertheless, when HTTPS is being used, the first thing that
 the user agent and the server have to do is negotiate the certificate. At this
 point, the HTTP headers have just NOT been sent yet.
 
-So how does the webserver decide which certificate to send ?
+So how does the web server decide which certificate to send ?
 
-.. note:: 10 years ago, that was simply not possible. The webservers had to send the same certificate for every virtualhost behind the same address and port.
+.. note:: 10 years ago, that was simply not possible. The web servers had to send the same certificate for every virtual host behind the same address and port.
 
 Nowadays, there is a TLS extension named **SNI**, which stands for Server
 Name Indication, which has been created to address this issue. SNI is supported