[Bug 63898] JSP EL generation is wrong when using newer version of Java 1.8 & tag class uses method overloading and isELIgnored="false

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63898 --- Comment #2 from Christopher Schultz --- Is there scope for Tomcat to either (a) pick the "best" method (based upon type-agreement) or (b) detect a conflict and throw an error? A consistent error would be much better than inconsistent failu

[Bug 63905] ErrorReportValve adds CSS even if both showReport and showServerInfo are set to false

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63905 Christopher Schultz changed: What|Removed |Added Keywords||Beginner -- You are receiving t

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #10 from Christopher Schultz --- Wild guess based only upon comments here: Java's TLSv1.3 implementation does not support TLS ESNI (encrypted SNI) extension. Usually, SNI is sent with initial TLS handshake. When the browser is in "

[Bug 63904] Apache http (with mod_jk to tomcat) randomly return empty response

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63904 Christopher Schultz changed: What|Removed |Added Resolution|--- |INVALID Status|NEW

[Bug 63905] New: ErrorReportValve adds CSS even if both showReport and showServerInfo are set to false

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63905 Bug ID: 63905 Summary: ErrorReportValve adds CSS even if both showReport and showServerInfo are set to false Product: Tomcat 8 Version: 8.5.x-trunk Hardware: All

[Bug 63898] JSP EL generation is wrong when using newer version of Java 1.8 & tag class uses method overloading and isELIgnored="false

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63898 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #9 from Mark Thomas --- https://bugs.openjdk.java.net/browse/JDK-8233619 I am resolving this Tomcat bug as invalid on the basis the root cause is a JVM TLSv1.3 bug. If the OpenJDK folks indicate that Tomcat is doing something wrong

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #8 from Remy Maucherat --- +1 I don't see how it can be a Tomcat issue at this point since the NOT_HANDSHAKING status occurs after running the task run(), without errors and without further wrapping or unwrapping. Working around i

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #7 from Mark Thomas --- This looks like a JVM bug to me. When Firefox's private browsing is enabled the penultimate handshake status is NEED_TASK. Immediately after calling tasks() the handshake status is NOT_HANDSHAKING rather tha

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #6 from Mark Thomas --- Interesting. The private browsing part is important. I can re-create this with the standard Tomcat certs we use in the unit tests now. Also seen on Linux and Firefox 70.0. I only see this with JSSE, not with

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #5 from Remy Maucherat --- Looking at it, it seems to do the same on Java 11, so the BZ is likely misleading. After unwrap there's a task being run, after the task is run in the tasks() method, the handshake status is returned as N

[Bug 63859] AJP cping/cpong mode failing on Tomcat 9.x

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63859 --- Comment #13 from Aurelien Pernoud --- Thanks Mark, appreciate all the time spent, I also agree this looks a complex one. Reading mod_jk logs it seems the cping / cpong is not coming back but as you also see the second httpd pointing to th

[Bug 63859] AJP cping/cpong mode failing on Tomcat 9.x

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63859 --- Comment #12 from Mark Thomas --- Thanks. I can't see anything obviously wrong in those files. The CPING is sent and the CPONG is never seen. If any Tomcat committer wants access to the logs, let me know and I'll send you a link. Debug log

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #4 from Mathias --- Created attachment 36872 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36872&action=edit tomcat 9.0.27 logfile -- You are receiving this mail because: You are the assignee for the bug.

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 Mathias changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Mathias --- Find at

[Bug 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake

2019-11-05 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 --- Comment #2 from Mathias --- Created attachment 36871 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36871&action=edit keystores for testing -- You are receiving this mail because: You are the assignee for the bug.