This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/mina-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 614b46c14 Updated site from master
(f1380b160a51fbba5bca89c29dfa59da0a6e694c)
614b46c14 is described below
commit 614b46c14004dcd27d4f33cb50b2fe88d54792c7
Author: jenkins <bui...@apache.org>
AuthorDate: Thu Dec 1 22:00:56 2022 +0000
Updated site from master (f1380b160a51fbba5bca89c29dfa59da0a6e694c)
---
content/index.xml | 4 ++--
content/mina-project/2.2-vs-2.1.html | 12 ++++++------
content/mina-project/index.xml | 4 ++--
content/sitemap.xml | 4 ++--
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/content/index.xml b/content/index.xml
index 8a3452630..226382671 100644
--- a/content/index.xml
+++ b/content/index.xml
@@ -1657,8 +1657,8 @@ It was decided to change that and make it easier for the
application to get this
<guid>https://mina.apache.org/mina-project/2.2-vs-2.1.html</guid>
<description>2.2.x vs 2.1.x differences The SSL/TLS handling has been
totally rewritten in MINA 2.2. This has an impact in many areas.
-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.
-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.</description>
+Removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute 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 sent by an application (an LDAP
client, for instance), which tells the server it should establish the SSL/TLS
layer.</description>
</item>
<item>
diff --git a/content/mina-project/2.2-vs-2.1.html
b/content/mina-project/2.2-vs-2.1.html
index 620b9f373..3d208efcd 100644
--- a/content/mina-project/2.2-vs-2.1.html
+++ b/content/mina-project/2.2-vs-2.1.html
@@ -119,9 +119,9 @@
<h1 id="22x-vs-21x-differences">2.2.x vs 2.1.x differences</h1>
<p>The <strong>SSL/TLS</strong> handling has been totally rewritten in
<strong>MINA 2.2</strong>. This has an impact in many areas.</p>
<h2 id="removal-of-the-sslfilterdisable_encryption_once-attribute">Removal of
the SslFilter.DISABLE_ENCRYPTION_ONCE attribute</h2>
-<p>This attribute was used in previous <strong>MINA</strong> versions to
insure that we can send some clear text message to the remote peer while
establishing the TLS connection when using the <strong>startTLS</strong>
command.</p>
-<p>The idea is that the <strong>startTLS</strong> command is send by an
application (a <strong>LDAP</strong> client, for instance), which tells the
server it should establish the <strong>SSL/TLS</strong> layer. But the problem
is that the server should be able to inform the clinet that the
<strong>SSL/TLS</strong> layer is up and running, in clear text, which is not
possible as the <strong>SSL/TLS</strong> layer is already
fonctionning…</p>
-<p>This kind of chicken/egg problem was solved by giving the opportunity to
the <strong>SSL/TLS</strong> layer to send back the <strong>startTLS</strong>
response to the client in clear text, assuming it’s the first
server’s message. A kind of a hack.</p>
+<p>This attribute was used in previous <strong>MINA</strong> versions to
insure that we can send a clear text message to the remote peer while
establishing the TLS connection when using the <strong>startTLS</strong>
command.</p>
+<p>The idea is that the <strong>startTLS</strong> command is sent by an
application (an <strong>LDAP</strong> client, for instance), which tells the
server it should establish the <strong>SSL/TLS</strong> layer. The problem is
that the server should be able to inform the client that the
<strong>SSL/TLS</strong> layer is up and running, in clear text, which is not
possible as the <strong>SSL/TLS</strong> layer is already
fonctionning…</p>
+<p>This kind of chicken and egg problem was solved by giving the opportunity
to the <strong>SSL/TLS</strong> layer to send back the
<strong>startTLS</strong> response to the client in clear text, assuming
it’s the server’s first message. A bit of a hack.</p>
<p>In <strong>MINA 2.2</strong>, 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
<strong>DisableEncryptWriteRequest</strong> interface.</p>
<p>Typically, in <strong>Apache Directory</strong>, we use this filter:</p>
<div class="highlight"><pre
style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code
class="language-java" data-lang="java"><span
style="color:#a2f;font-weight:bold">public</span> <span
style="color:#a2f;font-weight:bold">class</span> <span
style="color:#00f">StartTlsFilter</span> <span
style="color:#a2f;font-weight:bold">extends</span> IoFilterAdapter
@@ -154,13 +154,13 @@
<span style="color:#666">}</span>
<span style="color:#666">}</span>
-</code></pre></div><p>As we can see in this piece of code, we check if the
message is a <strong>startTLS</strong> response, and if so, we bypass the
<strong>SSLFilter</strong>, which leads to the message to be send in clear
text.</p>
+</code></pre></div><p>As you can see in the code above, we check if the
message is a <strong>startTLS</strong> response, and if so, we bypass the
<strong>SSLFilter</strong>, which leads to the message to be sent in clear
text.</p>
<h2 id="why-is-it-api-incompatible-">Why is it API incompatible ?</h2>
-<p>The removal of the <strong>SslFilter.DISABLE_ENCRYPTION_ONCE</strong>
attribute make it impossible for application that leverage the
<strong>startTLS</strong> command to work, without some code change.</p>
+<p>The removal of the <strong>SslFilter.DISABLE_ENCRYPTION_ONCE</strong>
attribute makes it impossible for application that leverage the
<strong>startTLS</strong> command to work, without some code change.</p>
<h2 id="migration">Migration</h2>
<p>This is pretty straightforward :</p>
<ul>
-<li>Create a filter that bypasses the message that should not be encrypted, or
encapsulate it into an inswtance that implements the
<strong>DisableEncryptWriteRequest</strong> interface</li>
+<li>Create a filter that bypasses the message that should not be encrypted, or
encapsulate it into an instance that implements the
<strong>DisableEncryptWriteRequest</strong> interface.</li>
</ul>
<p>and that’s it !</p>
diff --git a/content/mina-project/index.xml b/content/mina-project/index.xml
index 7754c3b55..ea044ddc3 100644
--- a/content/mina-project/index.xml
+++ b/content/mina-project/index.xml
@@ -706,8 +706,8 @@ It was decided to change that and make it easier for the
application to get this
<guid>https://mina.apache.org/mina-project/2.2-vs-2.1.html</guid>
<description>2.2.x vs 2.1.x differences The SSL/TLS handling has been
totally rewritten in MINA 2.2. This has an impact in many areas.
-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.
-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.</description>
+Removal of the SslFilter.DISABLE_ENCRYPTION_ONCE attribute 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 sent by an application (an LDAP
client, for instance), which tells the server it should establish the SSL/TLS
layer.</description>
</item>
<item>
diff --git a/content/sitemap.xml b/content/sitemap.xml
index 4aa6c019a..bcd68b5d7 100644
--- a/content/sitemap.xml
+++ b/content/sitemap.xml
@@ -829,7 +829,7 @@
<url>
<loc>https://mina.apache.org/mina-project/2.2-vs-2.1.html</loc>
- <lastmod>2022-07-18T14:53:10+02:00</lastmod>
+ <lastmod>2022-12-01T16:57:33-05:00</lastmod>
</url>
<url>
@@ -864,7 +864,7 @@
<url>
<loc>https://mina.apache.org/mina-project.html</loc>
- <lastmod>2022-07-24T23:18:44+02:00</lastmod>
+ <lastmod>2022-12-01T16:57:33-05:00</lastmod>
</url>
<url>
