[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.

2019-09-04 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690

--- Comment #17 from Mark Thomas  ---
https://bugs.chromium.org/p/chromium/issues/detail?id=1000809

The root cause currently looks to be a combination of how Chrome's buffering
interacts with flow control windows that do not have an initial size of n*16k
and Tomcat's recently added dislike of small, inefficient DATA frames as
potentially abusive.

While investigating this issue I have found that Tomcat needs to make some
changes to ensure that non-default initial window sizes are communicated to the
client as early as possible. I'll commit those after I have completed some more
testing.

I'm also looking into modifying Tomcat's overhead protection so a single DATA
frame with a 1 byte payload isn't seen as abusive.

-- 
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 63690] [HTTP/2] The socket [*] associated with this connection has been closed.

2019-09-04 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690

--- Comment #16 from Mark Thomas  ---
The 2852*5, 2124, 2852*5, 2124, 2852*5, 2124, 2852*5, 2123, 1, etc pattern
occurs (in Chrome at least) with a direct POST request with no libraries
present. That points to Chrome being responsible for the 1 byte DATA frame.
I'll try and reach out to a contact in the Chrome dev team.

-- 
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



buildbot failure in on tomcat-trunk

2019-09-04 Thread buildbot
The Buildbot has detected a new failure on builder tomcat-trunk while building 
tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4574

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 8d7aba9388b4786293cb6c4d8fe1f766a4b12b13
Blamelist: Christopher Schultz ,Mark Thomas 


BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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



[Bug 63724] Compile JSP to class when using Tiles and custom tag fails

2019-09-04 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63724

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Mark Thomas  ---
Please provide the simplest possible example (which is probably going to be a
WAR file) - including source - that demonstrates this issue.

-- 
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 63625] Unable to start Tomcat 7.0.96 (stop by 0xc0000005)

2019-09-04 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63625

--- Comment #22 from Christopher Schultz  ---
(In reply to Rainer Jung from comment #21)
> Probably this one:

[snip]

> -typedef int (__stdcall *WPUTENV) (const wchar_t *env);
> +typedef int (*WPUTENV) (const wchar_t *env);

OH.

I didn't realize WE were responsible for declaring the prototype of the call.
Makes sense, now.

-- 
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 8.5.x updated: Describe how Tomcat inherits its cryptographic support from the available libraries.

2019-09-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 720b8c6  Describe how Tomcat inherits its cryptographic support from 
the available libraries.
720b8c6 is described below

commit 720b8c62971ca498bd050c8f05b0046ced273bc4
Author: Christopher Schultz 
AuthorDate: Wed Sep 4 12:25:52 2019 -0400

Describe how Tomcat inherits its cryptographic support from the
available libraries.
---
 webapps/docs/ssl-howto.xml | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index c6b554a..7dff058 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -102,6 +102,24 @@ client are taking place over a secure connection (because 
your application
 needs to be able to ask about this), but it does not participate in the
 encryption or decryption itself.
 
+Tomcat is able to use any of the the cryptographic protocols that are
+provided by the underlying environment. Java itself provides cryptographic
+capabilities through https://docs.oracle.com/javase/9/security/java-cryptography-architecture-jca-reference-guide.htm;>JCE/JCA
+and encrypted communications capabilities through https://docs.oracle.com/javase/9/security/java-secure-socket-extension-jsse-reference-guide.htm;>JSSE.
+Any compliant cryptographic "provider" can provide cryptographic algorithms
+to Tomcat. The built-in provider (SunJCE) includes support for various
+SSL/TLS versions like SSLv3, TLSv1, TLSv1.1, and so on. Check the documentation
+for your version of Java for details on protocol and algorithm support.
+
+If you use the optional tcnative library, you can use
+the https://www.openssl.org/;>OpenSSL cryptographic provider
+through JCA/JCE/JSSE which may provide a different selection of cryptographic
+algorithms and/or performance benefits relative to the SunJCE provider.
+You can also use tcnative to enable the APR
+connector which uses OpenSSL for its cryptographic operations. Check the
+documentation for your version of OpenSSL for details on protocol and
+algorithm support.
+
 
 
 


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



[tomcat] branch master updated: Describe how Tomcat inherits its cryptographic support from the available libraries.

2019-09-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

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


The following commit(s) were added to refs/heads/master by this push:
 new 8d7aba9  Describe how Tomcat inherits its cryptographic support from 
the available libraries.
8d7aba9 is described below

commit 8d7aba9388b4786293cb6c4d8fe1f766a4b12b13
Author: Christopher Schultz 
AuthorDate: Wed Sep 4 12:25:52 2019 -0400

Describe how Tomcat inherits its cryptographic support from the
available libraries.
---
 webapps/docs/ssl-howto.xml | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/webapps/docs/ssl-howto.xml b/webapps/docs/ssl-howto.xml
index c6b554a..7dff058 100644
--- a/webapps/docs/ssl-howto.xml
+++ b/webapps/docs/ssl-howto.xml
@@ -102,6 +102,24 @@ client are taking place over a secure connection (because 
your application
 needs to be able to ask about this), but it does not participate in the
 encryption or decryption itself.
 
+Tomcat is able to use any of the the cryptographic protocols that are
+provided by the underlying environment. Java itself provides cryptographic
+capabilities through https://docs.oracle.com/javase/9/security/java-cryptography-architecture-jca-reference-guide.htm;>JCE/JCA
+and encrypted communications capabilities through https://docs.oracle.com/javase/9/security/java-secure-socket-extension-jsse-reference-guide.htm;>JSSE.
+Any compliant cryptographic "provider" can provide cryptographic algorithms
+to Tomcat. The built-in provider (SunJCE) includes support for various
+SSL/TLS versions like SSLv3, TLSv1, TLSv1.1, and so on. Check the documentation
+for your version of Java for details on protocol and algorithm support.
+
+If you use the optional tcnative library, you can use
+the https://www.openssl.org/;>OpenSSL cryptographic provider
+through JCA/JCE/JSSE which may provide a different selection of cryptographic
+algorithms and/or performance benefits relative to the SunJCE provider.
+You can also use tcnative to enable the APR
+connector which uses OpenSSL for its cryptographic operations. Check the
+documentation for your version of OpenSSL for details on protocol and
+algorithm support.
+
 
 
 


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



[Bug 63724] New: Compile JSP to class when using Tiles and custom tag fails

2019-09-04 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63724

Bug ID: 63724
   Summary: Compile JSP to class when using Tiles and custom tag
fails
   Product: Tomcat 9
   Version: 9.0.21
  Hardware: All
OS: Mac OS X 10.1
Status: NEW
  Severity: major
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: guilherm...@gmail.com
  Target Milestone: -

Created attachment 36758
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36758=edit
stacktrace

The commit "Replace custom split(String,String) method with call to
String.split by Christopher Schultz on 08/05/19 at 21:55 and git hash
f7c41d120c6374a8221b684a5ad5ede3d1621ff4" introduced a bug in the version of
Apache Tomcat 9.0.21 where the jsp pages using taglibs within struts tiles
template are no longer being parsed properly.


I got the latest git version and revert the commit
(f7c41d120c6374a8221b684a5ad5ede3d1621ff4) mentioned above. The jsp pages are
being parsed properly again.

This is bug under jasper.jar / class org.apache.jasper.compiler.JspUtil.java

-- 
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