Fix typos and ill-constructed sentences

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

1 files changed, 9 insertions, 9 deletions

diff --git a/posts/curl-and-the-tls-sni-extension.rst b/posts/curl-and-the-tls-sni-extension.rst
index b269fc2..1753dd5 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 differents websites. i.e. the *Host*
-HTTP header is analysed by your webserver so it can make the decision of which
-website it is going to serve.
+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
+decision of which website it is going to serve.
 
 However, these virtualhosts 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 virtualhosts:
 
 * example.org (it will be served by default because of the **default_server** directive),
 * vhost1.example.org,
@@ -180,7 +180,7 @@ So why does it fail ?
 
 Well, as we showed previously, the *Host* header is analysed to figure out which
 website to serve. Nevertheless, when HTTPS is being used, the first thing that
-the user agent and the server have to do is negociate the certificate. At this
+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 ?
@@ -198,7 +198,7 @@ TLS stack and can thus use SNI even under XP.
 
 Briefly, the extension works by sending the server name along with the first
 TLS packet. This way, the remote server knows which certificate to reply with.
-Only then, after the certificate has been negociated, the server can receives
+Only then, after the certificate has been negotiated, the server can receives
 the HTTP headers and is able to analyse the *Host* header.
 
 .. note:: The host header does not require to match with the server name that has been sent in the TLS packet.
@@ -207,7 +207,7 @@ So what can we do ?
 
 * We can still use the */etc/hosts* file as previously stated.
 * We can also use the **--resolve** option of cURL (which does pretty much the
-  same thing as modyfiying the */etc/hosts* file). The 443 is the port being
+  same thing as modifying the */etc/hosts* file). The 443 is the port being
   used: example::
 
         $ curl https://vhost1.example.org --resolve vhost1.example.org:443:176.31.99.217
@@ -215,7 +215,7 @@ So what can we do ?
         $ curl https://vhost2.example.org --resolve vhost2.example.org:443:176.31.99.217
         > vhost2
 
-* Or we can negociate one certificate that we know is good and then use the
+* Or we can negotiate one certificate that we know is good and then use the
   *Host* header to get the content of another website::
 
         $ curl https://example.org -H 'Host: vhost1.example.org'
@@ -223,7 +223,7 @@ So what can we do ?
         $ curl https://example.org -H 'Host: vhost2.example.org'
         > vhost2
 
-  We just negociated the certificate of *example.org* and got the content of
+  We just negotiated the certificate of *example.org* and got the content of
   another virtualhost ! We can verify::
 
         $ curl -v https://example.org -H 'Host: vhost1.example.org'