[Bug 63898] JSP EL generation is wrong when using newer version of Java 1.8 & tag class uses method overloading and isELIgnored="false
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 failure/success. -- 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 63905] ErrorReportValve adds CSS even if both showReport and showServerInfo are set to false
https://bz.apache.org/bugzilla/show_bug.cgi?id=63905 Christopher Schultz changed: What|Removed |Added Keywords||Beginner -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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 "private" mode, perhaps ESNI is used. Again, a wild guess. But it might explain what is happening, here. -- 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 63904] Apache http (with mod_jk to tomcat) randomly return empty response
https://bz.apache.org/bugzilla/show_bug.cgi?id=63904 Christopher Schultz changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Christopher Schultz --- The log shows that mod_jk can't tell whether the request was processed or not: > Client failed in the middle of request, we can't recover to another instance. mod_jk can't prove that the request could be idempotent, so failing-over to another server might be disastrous. There is nothing to be done but to fail the request. This is intended behavior in this case. My recommendation would be for you to review all your various timeouts to make sure mod_jk and Tomcat agree. Enable CPING/CPONG on the mod_jk end. See if that improves anything. If things are still behaving oddly, please post to the users list, as Bugzilla is not intended to be a support forum. We can always re-open this bug if there is indeed a bug (though mod_jk works in huge numbers of environments without problems, so a bug is unlikely). -- 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 63905] New: ErrorReportValve adds CSS even if both showReport and showServerInfo are set to false
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
OS: All
Status: NEW
Severity: minor
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: awalt...@gmail.com
Target Milestone:
According to the documentation for ErrorReportValve
(https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Error_Report_Valve),
disabling both showServerInfo and showReport will only return the HTTP status
code and remove all CSS, however after the fix for 60490
(https://bz.apache.org/bugzilla/show_bug.cgi?id=60490) this is no longer the
case and the error page returns responses like this:
HTTP Status 400 – Bad
Requesth1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}
b {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad Request
--
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 63898] JSP EL generation is wrong when using newer version of Java 1.8 & tag class uses method overloading and isELIgnored="false
https://bz.apache.org/bugzilla/show_bug.cgi?id=63898 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas --- TL;DR The JSP specification says that tags should only have one setter per property. I've spent some time looking into this an, interestingly, I have seen both behaviours with Oracle Java 8u172. I'm not sure if using a debugger influenced the behaviour or if other factors were involved. Digging into the JavaBeans Introspector code, when there are multiple setters and no other information to indicate that one should have priority over another (such as only one having a matching getter) then the first setter found it used. I suspect what is happening is that the order in which the methods are returned is varying since the various reflection class to obtain methods don't specify a return order. However, all of this is moot due to text present in the JSP specification. The section numbering seems a little off so if you search for the text "implication" and then look at the second instance you'll find the following: The setter methods that should be used when assigning a value to an attribute of a custom action are determined by using the JavaBeans introspector on the tag handler class, then use the setter method associated with the property that has the same name as the attribute in question. An implication (unclear in the JavaBeans specification) is that there is only one setter per property. Interestingly, it is only the name that is used to do the matching. The type is not used. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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, we can re-open this bug and investigate further. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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 it didn't work for me, I tried to return 0 (handshake complete) but then the engine is really not in "handshake finished" status so it fails. There's probably no way to escape this NOT_HANDSHAKING status once you go into it. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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 than finished. I'll write this up as an OpenJDK bug. I'll link to it here when that is done. We could work around it but it seems rare enough (at this point) that a workaround of "use OpenSSL if you need TLS 1.3 and are hitting this bug" is sufficient. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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 OpenSSL. I'm going to capture a couple of network traces to see if I can see a difference. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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 NOT_HANDSHAKING by the SSL engine. I don't understand what is going on or what the failure is at this point, but it might not be a Tomcat issue. We could probably add additional debug logging in SecureNio(2)Channel to trace the processing of handshake() when needed. 05-Nov-2019 11:09:26.157 FINE [https-jsse-nio-8443-exec-1] org.apache.tomcat.util.net.SecureNioChannel.handshake handshakeStatus: NEED_UNWRAP Run task: sun.security.ssl.SSLEngineImpl$DelegatedTask@4de31d09 sslEngine.getHandshakeStatus() after tasks: NEED_WRAP 05-Nov-2019 11:09:26.236 FINE [https-jsse-nio-8443-exec-1] org.apache.tomcat.util.net.SecureNioChannel.handshake handshakeStatus: NEED_WRAP 05-Nov-2019 11:09:26.237 FINE [https-jsse-nio-8443-exec-1] org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.registerWriteInterest Registered write interest for [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@1184d389:org.apache.tomcat.util.net.SecureNioChannel@1ebc5f1c:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8443 remote=/0:0:0:0:0:0:0:1:57612]] 05-Nov-2019 11:09:26.237 FINE [https-jsse-nio-8443-exec-2] org.apache.tomcat.util.net.SecureNioChannel.handshake handshakeStatus: NEED_WRAP 05-Nov-2019 11:09:26.238 FINE [https-jsse-nio-8443-exec-2] org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.registerWriteInterest Registered write interest for [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@1184d389:org.apache.tomcat.util.net.SecureNioChannel@1ebc5f1c:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8443 remote=/0:0:0:0:0:0:0:1:57612]] 05-Nov-2019 11:09:26.238 FINE [https-jsse-nio-8443-exec-3] org.apache.tomcat.util.net.SecureNioChannel.handshake handshakeStatus: NEED_WRAP 05-Nov-2019 11:09:26.247 FINE [https-jsse-nio-8443-exec-3] org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.registerReadInterest Registered read interest for [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@1184d389:org.apache.tomcat.util.net.SecureNioChannel@1ebc5f1c:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8443 remote=/0:0:0:0:0:0:0:1:57612]] 05-Nov-2019 11:09:26.251 FINE [https-jsse-nio-8443-exec-4] org.apache.tomcat.util.net.SecureNioChannel.handshake handshakeStatus: NEED_UNWRAP Run task: sun.security.ssl.SSLEngineImpl$DelegatedTask@427c714f sslEngine.getHandshakeStatus() after tasks: NOT_HANDSHAKING -- 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 63859] AJP cping/cpong mode failing on Tomcat 9.x
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 the same tomcat gets replies... So to me the issue is definitely in the cping cpong (mode A), but why does it fail sometimes, no idea ... Also as you can see in the logs the only server failing is the one running tomcat 9, all the others works fine, so to me the bug is on tomcat too. -- 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 63859] AJP cping/cpong mode failing on Tomcat 9.x
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 logging on the Tomcat side might be useful. Adding the following to logging.properties: org.apache.coyote.ajp.level = FINE org.apache.tomcat.util.net.level = FINE If that generates too much data, try starting with just the first of the two lines. Meanwhile, I am going to try and reproduce this. -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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=edit tomcat 9.0.27 logfile -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
https://bz.apache.org/bugzilla/show_bug.cgi?id=63892 Mathias changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Mathias --- Find attached the following keystores: client.p12 for import in Firefox 70.0.1. localhost.jks for the tomcat keystoreFile parameter client_certs.jks for the tomcat truststoreFile parameter No password needed for all of them. I always open a new private tab for testing with url https://localhost:8443/ -- 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 63892] TLS 1.3 with client auth fails with NOT_HANDSHAKING during handshake
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=edit keystores for testing -- 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
