This is an automated email from the ASF dual-hosted git repository.
ggregory pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mina-site.git
The following commit(s) were added to refs/heads/master by this push:
new f1380b160 Fix typos and clarify the text
f1380b160 is described below
commit f1380b160a51fbba5bca89c29dfa59da0a6e694c
Author: Gary Gregory <[email protected]>
AuthorDate: Thu Dec 1 16:57:33 2022 -0500
Fix typos and clarify the text
---
source/mina-project/2.2-vs-2.1.md | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/source/mina-project/2.2-vs-2.1.md
b/source/mina-project/2.2-vs-2.1.md
index 499feb3ea..d5deb8013 100644
--- a/source/mina-project/2.2-vs-2.1.md
+++ b/source/mina-project/2.2-vs-2.1.md
@@ -9,11 +9,11 @@ The **SSL/TLS** handling has been totally rewritten in **MINA
2.2**. This has an
## Removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute
-This attribute was used in previous **MINA** versions to insure that we can
send some clear text message to the remote peer while establishing the TLS
connection when using the **startTLS** command.
+This attribute was used in previous **MINA** versions to insure that we can
send a clear text message to the remote peer while establishing the TLS
connection when using the **startTLS** command.
-The idea is that the **startTLS** command is send by an application (a
**LDAP** client, for instance), which tells the server it should establish the
**SSL/TLS** layer. But the problem is that the server should be able to inform
the clinet that the **SSL/TLS** layer is up and running, in clear text, which
is not possible as the **SSL/TLS** layer is already fonctionning...
+The idea is that the **startTLS** command is sent by an application (an
**LDAP** client, for instance), which tells the server it should establish the
**SSL/TLS** layer. The problem is that the server should be able to inform the
client that the **SSL/TLS** layer is up and running, in clear text, which is
not possible as the **SSL/TLS** layer is already fonctionning...
-This kind of chicken/egg problem was solved by giving the opportunity to the
**SSL/TLS** layer to send back the **startTLS** response to the client in clear
text, assuming it's the first server's message. A kind of a hack.
+This kind of chicken and egg problem was solved by giving the opportunity to
the **SSL/TLS** layer to send back the **startTLS** response to the client in
clear text, assuming it's the server's first message. A bit of a hack.
In **MINA 2.2**, this attribute has been removed and replaced by either a
filter to be added, or by encapsulating the message that should not be
encrypted into an instance that implements the **DisableEncryptWriteRequest**
interface.
@@ -53,18 +53,17 @@ public class StartTlsFilter extends IoFilterAdapter
```
-As we can see in this piece of code, we check if the message is a **startTLS**
response, and if so, we bypass the **SSLFilter**, which leads to the message to
be send in clear text.
+As you can see in the code above, we check if the message is a **startTLS**
response, and if so, we bypass the **SSLFilter**, which leads to the message to
be sent in clear text.
## Why is it API incompatible ?
-The removal of the **SslFilter.DISABLE_ENCRYPTION_ONCE** attribute make it
impossible for application that leverage the **startTLS** command to work,
without some code change.
+The removal of the **SslFilter.DISABLE_ENCRYPTION_ONCE** attribute makes it
impossible for application that leverage the **startTLS** command to work,
without some code change.
## Migration
This is pretty straightforward :
-* Create a filter that bypasses the message that should not be encrypted, or
encapsulate it into an inswtance that implements the
**DisableEncryptWriteRequest** interface
+* Create a filter that bypasses the message that should not be encrypted, or
encapsulate it into an instance that implements the
**DisableEncryptWriteRequest** interface.
and that's it !
-
