svn commit: r1729786 - /mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext

[je...@apache.org]

Author: jeffmaury
Date: Thu Feb 11 09:49:02 2016
New Revision: 1729786

URL: http://svn.apache.org/viewvc?rev=1729786&view=rev
Log:
Add details

Modified:
    mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext

Modified: mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext
URL: http://svn.apache.org/viewvc/mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext?rev=1729786&r1=1729785&r2=1729786&view=diff
==============================================================================
--- mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext (original)
+++ mina/site/trunk/content/mina-project/userguide/ch11-ssl-filter/ch11-ssl-filter.mdtext Thu Feb 11 09:49:02 2016
@@ -71,6 +71,8 @@ First of all, you have to understand tha
 
 It was initially developed by **Netscape**, and named **SSL** (from 1.0 to 3.0), before becoming **TLS**. Nowadays, ***SSL 2.0** and **SSL 3.0** have been deprecated and should not be used.
 
+Please note that although the name include SSL, **SslFilter** supports TLS.
+
 
 ### The SSL/TLS protocol
 
@@ -104,7 +106,7 @@ We are all set. The next few steps are p
 
 This last point is important if you are to implement **StartTLS** : as it allows your application to switch from a plain text exchange to an encrypted exchange at any time, you have to be sure that there are not pending messages on both side. Obviously, on the client side - the side that initiates **StartTLS** - every pending messages will have been sent before the **StartTLS** message can be sent, but it has to block any other message that are not part of the following handshake, until the handshake is completed. On the server side, once the **StartTLS** message has been received, no message should be written to the remote peer.
 
-As a matter of fact, injecting the **SslFilter** in the chain should block any exchange that are not part of the handshake protocol until the handshake is completed.
+As a matter of fact, injecting the **SslFilter** in the chain should block any exchange that are not part of the handshake protocol until the handshake is completed. If you submit a message to be sent and encrypted before the handshake has been completed, the message will not be rejected but queued and will be processed when the handshake has been completed.
 
 Afterward, every message sent will go through the **SslHandler** instance to be encrypted, and every message received will have to be fully decrypted by the **SslHandler** before being available to the next filters.