[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #29 from Roman  ---
Thanks for the explanation and the fix!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #28 from Mark Thomas  ---
I was waiting for your test results before pushing the fix. This is the 9.0.x
fix:
https://github.com/apache/tomcat/commit/171a2cdc

The reason it is hard to reproduce is that it requires a specific set of
circumstances that are affected by timing.

The NIO connector uses a Poller when it needs to simulate blocking. If a write
can't complete immediately, the socket is added to the Poller and the write
continues when the Poller signals that the socket is ready for write.

The problem was the way Tomcat handled TLS writes. If the final non-encrypted
write for a response was fully encrypted but the encrypted data could not be
fully written, the socket was not added to the Poller. The final block of
encrypted data sat in the buffers until the connection timed out - at which
point it was flushed.

I was able to simulate this by configuring a VM with a slow connection
(128kbps) and then writing an ~80k file. By carefully adjusting the length of
the file, I was able to trigger this every time.

In a real system, triggering the issue would depend on how busy the network
stack was, how quickly the client read, the exact size of the response
(including headers) etc. The odds of hitting the exact combination are slim.

Fixed in:
- 10.1.x for 10.1.0-M3 onwards
- 10.0.x for 10.0.9 onwards
- 9.0.x for 9.0.51 onwards

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch main updated: Fix BZ 65448 for blocking IO

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new 6a65741  Fix BZ 65448 for blocking IO
6a65741 is described below

commit 6a65741d13fce5cccf6824d2be8685394878b9a3
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:56:00 2021 +0100

Fix BZ 65448 for blocking IO

If the write completes (from the application perspective) but the
encrypted data is not fully written, the connection (from the client's
perspective) will appear to hang until the client sends another request
(pipelining) or the connection times out.
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 8 ++--
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 5 +
 webapps/docs/changelog.xml| 6 ++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index ffdecc2..7865d42 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1339,7 +1339,11 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 n = getSocket().write(buffer);
 if (n == -1) {
 throw new EOFException();
-} else if (n == 0) {
+} else if (n == 0 && (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0)) {
+// n == 0 could be an incomplete write but it could 
also
+// indicate that a previous incomplete write of the
+// outbound buffer (for TLS) has now completed. Only
+// block if there is still data to write.
 writeBlocking = true;
 registerWriteInterest();
 synchronized (writeLock) {
@@ -1362,7 +1366,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 timeout = getWriteTimeout();
 startNanos = 0;
 }
-} while (buffer.hasRemaining());
+} while (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0);
 } else {
 do {
 n = getSocket().write(buffer);
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index 63af010..22e339f 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -801,6 +801,11 @@ public class SecureNioChannel extends NioChannel {
 return 0;
 }
 
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
+
 // The data buffer is empty, we can reuse the entire buffer.
 netOutBuffer.clear();
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 4cec1f7..3838cf3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -140,6 +140,12 @@
 connection that were trying to write when this happened would time out.
 (markt)
   
+  
+65448: When using TLS with NIO, it was possible for a
+blocking response write to hang just before the final TLS packet
+associated with the response until the connection timed out at which
+point the final packet would be sent and the connection closed. (markt)
+  
 
   
   

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 10.0.x updated: Fix BZ 65448 for blocking IO

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new a17e9d9  Fix BZ 65448 for blocking IO
a17e9d9 is described below

commit a17e9d9c0d59b8de86872997018cd47718129c46
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:56:00 2021 +0100

Fix BZ 65448 for blocking IO

If the write completes (from the application perspective) but the
encrypted data is not fully written, the connection (from the client's
perspective) will appear to hang until the client sends another request
(pipelining) or the connection times out.
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 8 ++--
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 5 +
 webapps/docs/changelog.xml| 6 ++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 42ddfcb..64cdfc6 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1337,7 +1337,11 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 n = getSocket().write(buffer);
 if (n == -1) {
 throw new EOFException();
-} else if (n == 0) {
+} else if (n == 0 && (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0)) {
+// n == 0 could be an incomplete write but it could 
also
+// indicate that a previous incomplete write of the
+// outbound buffer (for TLS) has now completed. Only
+// block if there is still data to write.
 writeBlocking = true;
 registerWriteInterest();
 synchronized (writeLock) {
@@ -1360,7 +1364,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 timeout = getWriteTimeout();
 startNanos = 0;
 }
-} while (buffer.hasRemaining());
+} while (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0);
 } else {
 do {
 n = getSocket().write(buffer);
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index 63af010..22e339f 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -801,6 +801,11 @@ public class SecureNioChannel extends NioChannel {
 return 0;
 }
 
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
+
 // The data buffer is empty, we can reuse the entire buffer.
 netOutBuffer.clear();
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d5debbc..3bc651f 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -140,6 +140,12 @@
 connection that were trying to write when this happened would time out.
 (markt)
   
+  
+65448: When using TLS with NIO, it was possible for a
+blocking response write to hang just before the final TLS packet
+associated with the response until the connection timed out at which
+point the final packet would be sent and the connection closed. (markt)
+  
 
   
   

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated: Fix BZ 65448 for blocking IO

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 171a2cd  Fix BZ 65448 for blocking IO
171a2cd is described below

commit 171a2cdce037af67f67f474f48848ba19c9b8766
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:56:00 2021 +0100

Fix BZ 65448 for blocking IO

If the write completes (from the application perspective) but the
encrypted data is not fully written, the connection (from the client's
perspective) will appear to hang until the client sends another request
(pipelining) or the connection times out.
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 8 ++--
 java/org/apache/tomcat/util/net/SecureNioChannel.java | 5 +
 webapps/docs/changelog.xml| 6 ++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index d4559bc..0f73308 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1364,7 +1364,11 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 n = getSocket().write(buffer);
 if (n == -1) {
 throw new EOFException();
-} else if (n == 0) {
+} else if (n == 0 && (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0)) {
+// n == 0 could be an incomplete write but it could 
also
+// indicate that a previous incomplete write of the
+// outbound buffer (for TLS) has now completed. Only
+// block if there is still data to write.
 writeBlocking = true;
 registerWriteInterest();
 synchronized (writeLock) {
@@ -1387,7 +1391,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 timeout = getWriteTimeout();
 startNanos = 0;
 }
-} while (buffer.hasRemaining());
+} while (buffer.hasRemaining() || 
getSocket().getOutboundRemaining() > 0);
 } else {
 do {
 n = getSocket().write(buffer);
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index 63af010..22e339f 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -801,6 +801,11 @@ public class SecureNioChannel extends NioChannel {
 return 0;
 }
 
+if (!src.hasRemaining()) {
+// Nothing left to write
+return 0;
+}
+
 // The data buffer is empty, we can reuse the entire buffer.
 netOutBuffer.clear();
 
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 8e28ef8..3a234be 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -140,6 +140,12 @@
 connection that were trying to write when this happened would time out.
 (markt)
   
+  
+65448: When using TLS with NIO, it was possible for a
+blocking response write to hang just before the final TLS packet
+associated with the response until the connection timed out at which
+point the final packet would be sent and the connection closed. (markt)
+  
 
   
   

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

JDK 17 is now in Rampdown Phase Two

[Rory O'Donnell]

Hi Mark,

*Per the JDK 17 schedule , we are in Rampdown Phase Two [1].*

*Please advise if you find any issues while testing the latest Early 
Access builds.*


 * Schedule:

 o *2021/07/15 Rampdown Phase Two*
 o 2021/08/05  Initial Release Candidate
 o 2021/08/19 Final Release Candidate
 o 2021/09/14  General Availability


The overall feature set is frozen. No further JEPs will be targeted to 
this release.


 * Features integrated in JDK 17:

 o JEP 306: Restore Always-Strict Floating-Point Semantics
   
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 403: Strongly Encapsulate JDK Internals
   
 o JEP 406: Pattern Matching for switch (Preview)
   
 o JEP 407: Remove RMI Activation 
 o JEP 409: Sealed Classes 
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   
 o JEP 411: Deprecate the Security Manager for Removal
   
 o JEP 412: Foreign Function & Memory API (Incubator)
   
 o JEP 414: Vector API (Second Incubator)
   
 o JEP 415: Context-Specific Deserialization Filters
   

*
*

*OpenJDK 17 Early Access build 31 is available at 
**https://jdk.java.net/17* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Release Notes are available at https://jdk.java.net/17/release-notes
   


*
*

*OpenJDK 18 Early Access build 6 is available at * 
*https://jdk.java.net/18* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Release Notes are available at https://jdk.java.net/18/release-notes
   
 * Changes in recent builds that maybe of interest:
 o JDK-8269697: JNI_GetPrimitiveArrayCritical() should not accept
   object array [build 6]
 o JDK-8253119: Remove the legacy PlainSocketImpl and
   PlainDatagramSocketImpl implementation [build 6]
 o JDK-8268960: Prohibit Null for Header Keys and Values in
   com.sun.net.httpserver.Headers [build 5]
 o JDK-8256425: Obsolete Biased Locking in JDK 18 [build 4]

*Topics of Interest: *

 * ‘Inside Java’ Podcast #18: Java's steady march towards strong
   encapsulation 


Rgds,Rory

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005752.html 

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #27 from Roman  ---
It would also be interesting what makes this environment so special that the
issue is so hard to reproduce.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #26 from Roman  ---
With v9.0.51-171a2cd, I can no longer reproduce the problem (with NIO+APR).
Very well done, thank you!
Out of curiosity, what was the fix? Is there a git commit that would show the
necessary changes?
Again, thank you for your quick help and support!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #25 from Mark Thomas  ---
I think this is fixed. Please test v9.0.51-171a2cd and report back. Debug
logging has been removed. You can removed any additional debug log settings
from logging.properties.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 9.0.x updated: Improve comments

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 89e4b2a  Improve comments
89e4b2a is described below

commit 89e4b2af74df6a365e96c39acc59c8e63fc14334
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:59:51 2021 +0100

Improve comments
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 10 +-
 java/org/apache/tomcat/util/net/SecureNioChannel.java |  2 --
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index 234747c..d4559bc 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1340,7 +1340,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
  * write it as part of a subsequent write call.
  *
  * Because of the above, when a timeout is triggered we 
need
- * so skip subsequent attempts to write as otherwise it 
will
+ * to skip subsequent attempts to write as otherwise it 
will
  * appear to the client as if some data was dropped just
  * before the connection is lost. It is better if the 
client
  * just sees the dropped connection.
@@ -1388,10 +1388,6 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 startNanos = 0;
 }
 } while (buffer.hasRemaining());
-// If there is data left in the buffer the socket will be 
registered for
-// write further up the stack. This is to ensure the socket is 
only
-// registered for write once as both container and user code 
can trigger
-// write registration.
 } else {
 do {
 n = getSocket().write(buffer);
@@ -1399,6 +1395,10 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 throw new EOFException();
 }
 } while (n > 0 && buffer.hasRemaining());
+// If there is data left in the buffer the socket will be 
registered for
+// write further up the stack. This is to ensure the socket is 
only
+// registered for write once as both container and user code 
can trigger
+// write registration.
 }
 updateLastWrite();
 }
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index de47904..63af010 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -788,8 +788,6 @@ public class SecureNioChannel extends NioChannel {
 public int write(ByteBuffer src) throws IOException {
 checkInterruptStatus();
 if (src == this.netOutBuffer) {
-//we can get here through a recursive call
-//by using the NioBlockingSelector
 int written = sc.write(src);
 return written;
 } else {

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch main updated: Improve comments

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
 new ef6f15d  Improve comments
ef6f15d is described below

commit ef6f15d82443568d8a92838eff47850d0378c349
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:59:51 2021 +0100

Improve comments
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 10 +-
 java/org/apache/tomcat/util/net/SecureNioChannel.java |  2 --
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index c50c720..ffdecc2 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1315,7 +1315,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
  * write it as part of a subsequent write call.
  *
  * Because of the above, when a timeout is triggered we 
need
- * so skip subsequent attempts to write as otherwise it 
will
+ * to skip subsequent attempts to write as otherwise it 
will
  * appear to the client as if some data was dropped just
  * before the connection is lost. It is better if the 
client
  * just sees the dropped connection.
@@ -1363,10 +1363,6 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 startNanos = 0;
 }
 } while (buffer.hasRemaining());
-// If there is data left in the buffer the socket will be 
registered for
-// write further up the stack. This is to ensure the socket is 
only
-// registered for write once as both container and user code 
can trigger
-// write registration.
 } else {
 do {
 n = getSocket().write(buffer);
@@ -1374,6 +1370,10 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 throw new EOFException();
 }
 } while (n > 0 && buffer.hasRemaining());
+// If there is data left in the buffer the socket will be 
registered for
+// write further up the stack. This is to ensure the socket is 
only
+// registered for write once as both container and user code 
can trigger
+// write registration.
 }
 updateLastWrite();
 }
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index de47904..63af010 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -788,8 +788,6 @@ public class SecureNioChannel extends NioChannel {
 public int write(ByteBuffer src) throws IOException {
 checkInterruptStatus();
 if (src == this.netOutBuffer) {
-//we can get here through a recursive call
-//by using the NioBlockingSelector
 int written = sc.write(src);
 return written;
 } else {

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch 10.0.x updated: Improve comments

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/10.0.x by this push:
 new 590d65e  Improve comments
590d65e is described below

commit 590d65e24a6f987ae57d8c8ab83949c6baaef263
Author: Mark Thomas 
AuthorDate: Thu Jul 15 16:59:51 2021 +0100

Improve comments
---
 java/org/apache/tomcat/util/net/NioEndpoint.java  | 10 +-
 java/org/apache/tomcat/util/net/SecureNioChannel.java |  2 --
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
b/java/org/apache/tomcat/util/net/NioEndpoint.java
index c07fd07..42ddfcb 100644
--- a/java/org/apache/tomcat/util/net/NioEndpoint.java
+++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
@@ -1313,7 +1313,7 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
  * write it as part of a subsequent write call.
  *
  * Because of the above, when a timeout is triggered we 
need
- * so skip subsequent attempts to write as otherwise it 
will
+ * to skip subsequent attempts to write as otherwise it 
will
  * appear to the client as if some data was dropped just
  * before the connection is lost. It is better if the 
client
  * just sees the dropped connection.
@@ -1361,10 +1361,6 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 startNanos = 0;
 }
 } while (buffer.hasRemaining());
-// If there is data left in the buffer the socket will be 
registered for
-// write further up the stack. This is to ensure the socket is 
only
-// registered for write once as both container and user code 
can trigger
-// write registration.
 } else {
 do {
 n = getSocket().write(buffer);
@@ -1372,6 +1368,10 @@ public class NioEndpoint extends 
AbstractJsseEndpoint
 throw new EOFException();
 }
 } while (n > 0 && buffer.hasRemaining());
+// If there is data left in the buffer the socket will be 
registered for
+// write further up the stack. This is to ensure the socket is 
only
+// registered for write once as both container and user code 
can trigger
+// write registration.
 }
 updateLastWrite();
 }
diff --git a/java/org/apache/tomcat/util/net/SecureNioChannel.java 
b/java/org/apache/tomcat/util/net/SecureNioChannel.java
index de47904..63af010 100644
--- a/java/org/apache/tomcat/util/net/SecureNioChannel.java
+++ b/java/org/apache/tomcat/util/net/SecureNioChannel.java
@@ -788,8 +788,6 @@ public class SecureNioChannel extends NioChannel {
 public int write(ByteBuffer src) throws IOException {
 checkInterruptStatus();
 if (src == this.netOutBuffer) {
-//we can get here through a recursive call
-//by using the NioBlockingSelector
 int written = sc.write(src);
 return written;
 } else {

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: https://bz.apache.org/bugzilla/show_bug.cgi?id=55707 in tomcat

[jean-frederic clere]

On 13/07/2021 11:03, jean-frederic clere wrote:

On 09/07/2021 18:40, Rainer Jung wrote:

Hi Jean-Frederic,

how do you make sure, that your tests actually land in the correct 
SSLHost? You are using the same server certificate, so a check on the 
client side might not be easy. I would find a test more convincing, if 
the three TLS hosts would use three different certificates and you 
could check on the TLS client, that it actually gets the right server 
certificate.


Yes I have retested with 3 different certificates
localhost gets the localhost certificate and the TLSv1.1 protocol
server1 gets the server1 certificate but the TLSv1.1 protocol
server2 gets the server2 certificate but the TLSv1.1 protocol...

Use nio/nio2 the protocol is the expected one.


https://github.com/apache/tomcat-native/pull/10 the fix for it.





Best regards,

Rainer

Am 09.07.2021 um 15:33 schrieb jean-frederic clere:

On 09/07/2021 15:15, Christopher Schultz wrote:

Jean-Ferderic,

On 7/9/21 07:55, jean-frederic clere wrote:

On 09/07/2021 12:38, Mark Thomas wrote:

On 09/07/2021 11:08, jean-frederic clere wrote:

Hi,

I think we need the same fix in tomcat or I missed something?

If we need it I will work on it next week ;-)


To clarify, you mean checking Tomcat can (and implementing if it 
can't) the ability to configure supported SSL protocols per 
virtual host.


Yes.



We should have most of this in SSLHostConfig but I don't recall 
ever testing this behaviour specifically.


Just as a reminder, both  elements and .../> are likely to be required as the are configured separately.


Quick test and code review seems to show it is not working (I 
tested the apr connector and 9.0.x).


Can you post a sample config?

I assume you mean:

1. Define two , configure for TLS
   a. One attempting to use e.g. only TLSv1
   b. One attempting to use e.g. only TLSv1.2

2. Run a protocol-checker against both hosts

Result is that host (a) supports not-only TLSv1 and/or host (b) 
supports not-only TLSv1.2?


Yes that is what I am testing, actually Nio and Nio2 are working Apr 
isn't...


The configuration is something like:
+++
    
   
   
   
   
   
   
   
   
   
    
+++
and I have the 3 corresponding 






--
Cheers

Jean-Frederic


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #24 from Roman  ---
Sounds great!
I have attached of the second run. This time, it blocked the very first time.
The second time, it worked normally.
Unfortunatelly, we are using our own log manager and thus I am not sure whether
we can include the thread names.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #23 from Roman  ---
Created attachment 37956
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37956=edit
Logs of v2, with screenshot of cURL/Log-Tail when it blocked

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #22 from Mark Thomas  ---
I have been able to recreate something locally that may well be the same issue
you are seeing. The v2 logs should confirm it. I'm working on a fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #21 from Mark Thomas  ---
Thanks for running the test. It is likely that the issue was harder to
reproduce due to the additional logging.

You appear to be using a non-default log format. It would be helpful if the
Thread name could be restored  but I can work without it if that makes the
issue harder to reproduce.

Reviewing the logs has identified something I want to look at a little more
closely. I've reworked the log messages to try and reduce the impact of the
logging.

Please can you retest with v9.0.51-bz-65448-v2 and post the resulting logs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat-native] jfclere opened a new pull request #10: fix an issue similar to BZ 55707

[GitBox]

jfclere opened a new pull request #10:
URL: https://github.com/apache/tomcat-native/pull/10


   Fix an issue similar to https://bz.apache.org/bugzilla/show_bug.cgi?id=55707
   
   note it affects only the Apr connector it seems.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #20 from Roman  ---
I have attached the full logs of the test run with v1.
It took quite some tries to actually reproduce it, but I made a screenshot at
the time it happened so that you can correlate the blocking with timestamps in
the log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=65448

--- Comment #19 from Roman  ---
Created attachment 37955
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37955=edit
Logs of v1, with screenshot of cURL/Log-Tail when it blocked

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org