fixed typos and indentation.

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

1 files changed, 27 insertions, 26 deletions

diff --git a/posts/curl-and-the-tls-sni-extension.rst b/posts/curl-and-the-tls-sni-extension.rst
index 6bea31a..39d3f35 100644
--- a/posts/curl-and-the-tls-sni-extension.rst
+++ b/posts/curl-and-the-tls-sni-extension.rst
@@ -86,7 +86,7 @@ Let's try that out with HTTP::
     $ curl http://176.31.99.217
     default
 
-The default server is served because 172.31.99.217 does not match any
+The default website is served because 172.31.99.217 does not match any
 virtualhost *server_name* directive::
 
     $ curl http://vhost1.example.org
@@ -112,7 +112,7 @@ We are offered (at least) two possibilities:
         vhost2
 
 * specifying the **Host** header manually using the option **-H** of cURL. This
-  is the recommended way in most cases.
+  is my favorite way in most cases.
   Example::
 
         $ curl http://176.31.99.217 -H 'Host: vhost1.example.org'
@@ -150,8 +150,8 @@ 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 as
-before (unless you didn't clear your */etc/hosts* file.::
+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).::
 
     $ curl https://vhost1.example.org
     curl: (6) Could not resolve host: vhost1.example.org
@@ -160,22 +160,22 @@ before (unless you didn't clear your */etc/hosts* file.::
 
 The good news is: it will still work if you modify your */etc/hosts* file (huray)::
 
-        $ cat /etc/hosts
-        127.0.0.1       localhost
-        176.31.99.217   vhost1.example.org
-        176.31.99.217   vhost2.example.org
+    $ cat /etc/hosts
+    127.0.0.1       localhost
+    176.31.99.217   vhost1.example.org
+    176.31.99.217   vhost2.example.org
 
-        $ curl https://vhost1.example.org
-        vhost1
-        $ curl https://vhost2.example.org
-        vhost2
+    $ curl https://vhost1.example.org
+    vhost1
+    $ curl https://vhost2.example.org
+    vhost2
 
 And the bad news is::
 
-        $ curl https://176.31.99.217 -H 'Host: vhost1.example.org'
-        curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217'
-        $ curl https://176.31.99.217 -H 'Host: vhost2.example.org'
-        curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217'
+    $ curl https://176.31.99.217 -H 'Host: vhost1.example.org'
+    curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217'
+    $ curl https://176.31.99.217 -H 'Host: vhost2.example.org'
+    curl: (51) SSL: certificate subject name 'example.org' does not match target host name '176.31.99.217'
 
 So why does it fail ?
 
@@ -184,22 +184,23 @@ 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
 point, the HTTP headers have just NOT been sent yet.
 
-So how does the webserver decides which certificate to send ?
+So how does the webserver decide which certificate to send ?
 
-.. note:: 10 years ago, it 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 webservers had to send the same certificate for every virtualhost behind the same address and port.
 
-Nowadays, there is a TLS extension, SNI (which stands for Server Name
-Indication) that is supported by most browsers and operating systems. The TLS
-stack present in Windows XP does not support it. As a consequence, Internet
-Explorer under Windows XP cannot use SNI. But most other browsers use their own
+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
+by most browsers and operating systems. However, the TLS stack present in
+Windows XP does not support it. As a consequence, Internet Explorer under
+Windows XP cannot use SNI. But most other browsers use their own
 TLS stack and can thus use SNI even under XP.
 
 .. note:: See more on Wikipedia: https://en.wikipedia.org/wiki/Server_Name_Indication
 
 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, that the server can
-analyse the *Host* header.
+Only then, after the certificate has been negociated, 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,8 +208,8 @@ 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
-  used): example::
+  same thing as modyfiying 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
         > vhost1