[Bug 64021] SCI ordering prevents a web application SCI from using a service bootstrapped by a container-provided SCI
https://bz.apache.org/bugzilla/show_bug.cgi?id=64021 --- Comment #4 from mgrigorov --- There is a known problem with SCI in 7.0.100 7.0.103 is being voted at the moment. You could test it from https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/bin/ -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Tomcat tightened up the HTTP 0.9 parsing. It looks like there is an issue with requests of the form: GET / LF Prior to the parsing changes, this would have been accepted as a (malformed) HTTP 0.9 request. It is now rejected as an invalid HTTP 1.1 request. The HTTP 0.9 spec allows either way of handling the request. I'll take a look to see if the parsing can be relaxed to accept requests like this without creating problems elsewhere. I'm curious. What clients are you using that sent malformed HTTP 0.9 requests? -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #2 from dingli <382188...@qq.com> --- (In reply to Mark Thomas from comment #1) > Tomcat tightened up the HTTP 0.9 parsing. It looks like there is an issue > with requests of the form: > > GET / LF > > Prior to the parsing changes, this would have been accepted as a (malformed) > HTTP 0.9 request. It is now rejected as an invalid HTTP 1.1 request. The > HTTP 0.9 spec allows either way of handling the request. > > I'll take a look to see if the parsing can be relaxed to accept requests > like this without creating problems elsewhere. > > I'm curious. What clients are you using that sent malformed HTTP 0.9 > requests? my tomcat is behinde one F5 load balancer, F5 have http monitor to check the tomcat's health. The default send string of F5 http monitor is "GET /CRLF", total 7 bytes. when tomcat close the socket without return anything, F5 think tomcat is out of service. below is the tcpdump of F5 monitor connection: 22:45:04.215888 IP 172.16.97.5.15379 > 172.16.28.103.ircu-4: Flags [S], seq 3311525713, win 5840, options [mss 1460,sackOK,TS val 3987447303 ecr 0,nop,wscale 7], length 0 0x: 4500 003c 20ba 4000 3f06 4575 ac10 6105 E..<..@.?.Eu..a. 0x0010: ac10 1c67 3c13 1a0c c561 df51 ...g172.16.97.5.15379: Flags [S.], seq 3991552491, ack 3311525714, win 14480, options [mss 1460,sackOK,TS val 3320472856 ecr 3987447303,nop,wscale 7], length 0 0x: 4500 003c 4000 4006 652f ac10 1c67 E..<..@.@.e/...g 0x0010: ac10 6105 1a0c 3c13 edea 41eb c561 df52 ..a...<...A..a.R 0x0020: a012 3890 5872 0204 05b4 0402 080a ..8.Xr.. 0x0030: c5ea 6518 edab 9e07 0103 0307..e. 22:45:04.217823 IP 172.16.97.5.15379 > 172.16.28.103.ircu-4: Flags [.], ack 1, win 46, options [nop,nop,TS val 3987447305 ecr 3320472856], length 0 0x: 4500 0034 20bb 4000 3f06 457c ac10 6105 E..4..@.?.E|..a. 0x0010: ac10 1c67 3c13 1a0c c561 df52 edea 41ec ...g 172.16.28.103.ircu-4: Flags [P.], seq 1:8, ack 1, win 46, options [nop,nop,TS val 3987447305 ecr 3320472856], length 7 0x: 4500 003b 20bc 4000 3f06 4574 ac10 6105 E..;..@.?.Et..a. 0x0010: ac10 1c67 3c13 1a0c c561 df52 edea 41ec ...g 172.16.97.5.15379: Flags [.], ack 8, win 114, options [nop,nop,TS val 3320472858 ecr 3987447305], length 0 0x: 4500 0034 24f6 4000 4006 4041 ac10 1c67 E..4$.@.@.@A...g 0x0010: ac10 6105 1a0c 3c13 edea 41ec c561 df59 ..a...<...A..a.Y 0x0020: 8010 0072 bf51 0101 080a c5ea 651a ...r.Qe. 0x0030: edab 9e09 22:45:04.219749 IP 172.16.28.103.ircu-4 > 172.16.97.5.15379: Flags [F.], seq 1, ack 8, win 114, options [nop,nop,TS val 3320472860 ecr 3987447305], length 0 0x: 4500 0034 24f7 4000 4006 4040 ac10 1c67 E..4$.@.@.@@...g 0x0010: ac10 6105 1a0c 3c13 edea 41ec c561 df59 ..a...<...A..a.Y 0x0020: 8011 0072 bf4e 0101 080a c5ea 651c ...r.Ne. 0x0030: edab 9e09 22:45:04.220836 IP 172.16.97.5.15379 > 172.16.28.103.ircu-4: Flags [F.], seq 8, ack 2, win 46, options [nop,nop,TS val 3987447308 ecr 3320472860], length 0 0x: 4500 0034 20bd 4000 3f06 457a ac10 6105 E..4..@.?.Ez..a. 0x0010: ac10 1c67 3c13 1a0c c561 df59 edea 41ed ...g 172.16.97.5.15379: Flags [.], ack 9, win 114, options [nop,nop,TS val 3320472861 ecr 3987447308], length 0 0x: 4500 0034 24f8 4000 4006 403f ac10 1c67 E..4$.@.@.@?...g 0x0010: ac10 6105 1a0c 3c13 edea 41ed c561 df5a ..a...<...A..a.Z 0x0020: 8010 0072 bf49 0101 080a c5ea 651d ...r.Ie. 0x0030: edab 9e0c you can see the real payload data is "47 45 54 20 2f 0d 0a" (7 bytes in Hex) -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #3 from dingli <382188...@qq.com> --- (In reply to Mark Thomas from comment #1) > Tomcat tightened up the HTTP 0.9 parsing. It looks like there is an issue > with requests of the form: > > GET / LF > > Prior to the parsing changes, this would have been accepted as a (malformed) > HTTP 0.9 request. It is now rejected as an invalid HTTP 1.1 request. The > HTTP 0.9 spec allows either way of handling the request. > > I'll take a look to see if the parsing can be relaxed to accept requests > like this without creating problems elsewhere. > > I'm curious. What clients are you using that sent malformed HTTP 0.9 > requests? I think the "GET /CRLF" is a valid HTTP 0.9 requet in RFC1945: Simple-Request = "GET" SP Request-URI CRLF and one strange thing is sometime tomcat will response content for this kind of request and sometime won't. -- 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 64021] SCI ordering prevents a web application SCI from using a service bootstrapped by a container-provided SCI
https://bz.apache.org/bugzilla/show_bug.cgi?id=64021 --- Comment #5 from zhander...@huawei.com --- (In reply to mgrigorov from comment #4) > There is a known problem with SCI in 7.0.100 > 7.0.103 is being voted at the moment. You could test it from > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/bin/ Thanks, 7.0.103 is ok 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
[Bug 64021] SCI ordering prevents a web application SCI from using a service bootstrapped by a container-provided SCI
https://bz.apache.org/bugzilla/show_bug.cgi?id=64021 Remy Maucherat changed: What|Removed |Added Product|Tomcat 7|Tomcat 9 Target Milestone|--- |- Version|7.0.100 |9.0.31 Component|Catalina|Catalina -- 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 64021] SCI ordering prevents a web application SCI from using a service bootstrapped by a container-provided SCI
https://bz.apache.org/bugzilla/show_bug.cgi?id=64021 Remy Maucherat changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Remy Maucherat --- Please do not reopen this BZ. -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #4 from Remy Maucherat --- Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to still have it (clients which insist would still get something back). -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #5 from Michael Osipov --- (In reply to Remy Maucherat from comment #4) > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > still have it (clients which insist would still get something back). +1 for this in Tomcat 10. -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #6 from dingli <382188...@qq.com> --- (In reply to Remy Maucherat from comment #4) > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > still have it (clients which insist would still get something back). It is F5's default setting :( and we can't change F5's setting by ourselves :( -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #7 from Michael Osipov --- (In reply to dingli from comment #6) > (In reply to Remy Maucherat from comment #4) > > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > > still have it (clients which insist would still get something back). > > It is F5's default setting :( > and we can't change F5's setting by ourselves :( You have paid for a commercial product you should have support for that. mod_proxy does a simple HEAD request against / with HTTP/1.1. Works flawlessly. -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #8 from dingli <382188...@qq.com> --- (In reply to Michael Osipov from comment #7) > (In reply to dingli from comment #6) > > (In reply to Remy Maucherat from comment #4) > > > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > > > still have it (clients which insist would still get something back). > > > > It is F5's default setting :( > > and we can't change F5's setting by ourselves :( > > You have paid for a commercial product you should have support for that. > mod_proxy does a simple HEAD request against / with HTTP/1.1. Works > flawlessly. yes, we can make a ticket to network maintenance department and wait. it is a long time process :( anyway, the upgrade from 8.5.50 to 8.5.51/8.5.53 will break some tomcat instance behind F5 load balancer. -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 Remy Maucherat changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #9 from Remy Maucherat --- Anyway, about the actual "issue", I don't see how it happens right 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
[Bug 64243] New: Cannot find attribute maxThreads for org.apache.tomcat.util.net.SocketProperties
https://bz.apache.org/bugzilla/show_bug.cgi?id=64243 Bug ID: 64243 Summary: Cannot find attribute maxThreads for org.apache.tomcat.util.net.SocketProperties Product: Tomcat 8 Version: 8.5.51 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Manager Assignee: dev@tomcat.apache.org Reporter: onte...@gmail.com Target Milestone: Hello, Although marked as RESOLVED before(#62918 and #63641), I'm having same issue on 8.5.51. Could you check this issue? The Error trace is; javax.management.AttributeNotFoundException: Cannot find attribute maxThreads for org.apache.tomcat.util.net.SocketProperties@399200be at org.apache.tomcat.util.modeler.ManagedBean.getGetter(ManagedBean.java:435) at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:167) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) at newManager.StatusTransformer.writeConnectorState(StatusTransformer.java:250) at newManager.StatusManagerServlet.doGet(StatusManagerServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:634) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1623) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) -- 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 64243] Cannot find attribute maxThreads for org.apache.tomcat.util.net.SocketProperties
https://bz.apache.org/bugzilla/show_bug.cgi?id=64243 Jaeyoon "Jay" Lee changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Jaeyoon "Jay" Lee --- I found out there was error in my configuration. I guess there is no issue on tomcat, so i'll close it now. sorry -- 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
Re: [VOTE] Release Apache Tomcat 7.0.103
On Mon, Mar 16, 2020 at 5:13 AM Violeta Georgieva wrote: > The proposed Apache Tomcat 7.0.103 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1260/ > The git tag is: > https://github.com/apache/tomcat/tree/7.0.103 > c4e59ac215eebff2de5fd9d23fb37fe222bc99c5 > > The proposed 7.0.103 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 7.0.103 Stable > +1 > Regards, > Violeta >
[tomcat] branch master updated: Add a test case for BZ64240
This is an automated email from the ASF dual-hosted git repository.
remm 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 c870a1e Add a test case for BZ64240
c870a1e is described below
commit c870a1ea7f09b885ff724702562b3e1df14ff06e
Author: remm
AuthorDate: Thu Mar 19 14:49:21 2020 +0100
Add a test case for BZ64240
I couldn't reproduce it, so tried a test case (with some sleeps to see
if there would be some state problem when going to the poller). Works
for me.
---
.../coyote/http11/TestHttp11InputBuffer.java | 45 ++
1 file changed, 45 insertions(+)
diff --git a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
index a1d50d0..c9204a2 100644
--- a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
+++ b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
@@ -17,8 +17,15 @@
package org.apache.coyote.http11;
+import java.io.BufferedReader;
import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.io.OutputStream;
+import java.io.OutputStreamWriter;
import java.io.PrintWriter;
+import java.io.Writer;
+import java.net.Socket;
import java.util.Enumeration;
import jakarta.servlet.ServletException;
@@ -656,6 +663,44 @@ public class TestHttp11InputBuffer extends TomcatBaseTest {
@Test
+public void testValidHttp09() throws Exception {
+
+Tomcat tomcat = getTomcatInstance();
+
+tomcat.addContext("", TEMP_DIR);
+tomcat.start();
+
+Socket socket = null;
+OutputStream os = null;
+InputStream is = null;
+BufferedReader reader = null;
+Writer writer = null;
+final String encoding = "ISO-8859-1";
+
+for (int i = 0; i < 10; i++) {
+socket = new Socket("localhost", getPort());
+os = socket.getOutputStream();
+writer = new OutputStreamWriter(os, encoding);
+writer.write("GET /");
+writer.flush();
+Thread.sleep(10);
+writer.write(CR);
+writer.flush();
+Thread.sleep(10);
+writer.write(LF);
+writer.flush();
+is = socket.getInputStream();
+reader = new BufferedReader(new InputStreamReader(is));
+String line = reader.readLine();
+Assert.assertNotNull(line);
+Assert.assertTrue(line.indexOf("404") != -1);
+socket.close();
+}
+
+}
+
+
+@Test
public void testInvalidHttp09() {
String[] request = new String[1];
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #10 from Remy Maucherat --- I fail to see the problem so I added a test case to test HTTP/0.9 support (using "GET /CRLF"), and it works for me. -- 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 master updated: Rename poller thread
This is an automated email from the ASF dual-hosted git repository. remm 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 f1b9883 Rename poller thread f1b9883 is described below commit f1b98839d2ceda9e73b4cd756b813f377f2e4922 Author: remm AuthorDate: Thu Mar 19 16:50:12 2020 +0100 Rename poller thread With the removal of the BlockPoller, it makes sense to use a simpler name for the poller thread. --- java/org/apache/tomcat/util/net/NioEndpoint.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java b/java/org/apache/tomcat/util/net/NioEndpoint.java index b3947c9..b4da738 100644 --- a/java/org/apache/tomcat/util/net/NioEndpoint.java +++ b/java/org/apache/tomcat/util/net/NioEndpoint.java @@ -228,7 +228,7 @@ public class NioEndpoint extends AbstractJsseEndpoint // Start poller thread poller = new Poller(); -Thread pollerThread = new Thread(poller, getName() + "-ClientPoller"); +Thread pollerThread = new Thread(poller, getName() + "-Poller"); pollerThread.setPriority(threadPriority); pollerThread.setDaemon(true); pollerThread.start(); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RESULT][VOTE] Release Apache Tomcat 7.0.103
На пн, 16.03.2020 г. в 11:13 Violeta Georgieva написа: > > The proposed Apache Tomcat 7.0.103 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1260/ > The git tag is: > https://github.com/apache/tomcat/tree/7.0.103 > c4e59ac215eebff2de5fd9d23fb37fe222bc99c5 > > The proposed 7.0.103 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 7.0.103 Stable +1 (binding): mgrigorov, remm, violetagg, kkolinko, csutherl No other voters were cast. The vote has passed. I'll do the release shortly and announce it once the mirrors catch up. Regards, Violeta
Nexus: Promotion Completed
Message from: https://repository.apache.orgDeployer properties:"userAgent" = "maven-artifact/2.2.1 (Java 1.7.0_80; Windows 8.1 6.3)""userId" = "violetagg""ip" = "78.83.99.114"Details:The following artifacts have been promoted to the "Releases" [id=releases] repository/org/apache/tomcat/tomcat-i18n-de/7.0.103/tomcat-i18n-de-7.0.103.pom(SHA1: ded64d740088e8505f3a863c9dd542afb14660ed)/org/apache/tomcat/tomcat-i18n-de/7.0.103/tomcat-i18n-de-7.0.103.pom.asc(SHA1: 299c5cd7406b5c632ebf838cebf6cc6a36f66daa)/org/apache/tomcat/tomcat-i18n-de/7.0.103/tomcat-i18n-de-7.0.103.jar(SHA1: 0a0877676dda7222345a960bf22d1fae52cc04a3)/org/apache/tomcat/tomcat-i18n-de/7.0.103/tomcat-i18n-de-7.0.103.jar.asc(SHA1: 8365d94b72f2b976876f1d56ed743c239781f345)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103-sources.jar.asc(SHA1: 8a94de4f0b916a87d0787f1db4bacdd69a7180c6)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103.pom(SHA1: 74a71ac7adcc632d7ddd237c082269fd74e8311e)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103.jar.asc(SHA1: 063f4006ae925eae5b8de8d0ad719b40f08d72f0)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103-sources.jar(SHA1: 895186be311f9f0ddf2b602bbf2e76ed83c14ed0)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103.jar(SHA1: b943d808faacef5a892350a50ea8d5899d0cf059)/org/apache/tomcat/tomcat-juli/7.0.103/tomcat-juli-7.0.103.pom.asc(SHA1: 763498ea5e346b694d70cbc5e66ec6e3352ee7d9)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103-sources.jar(SHA1: 37d175bdbb55708a6343a1b764cccf76ba5de1b3)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103.pom(SHA1: ec2e47c6dd922e4ac1e62db6bcb2b5f5d50439cf)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103-sources.jar.asc(SHA1: 49aa450186498cdfc392ea48e2f2507c1cd9d391)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103.pom.asc(SHA1: c7b23f7a6738c70e3099ef8b338743dec9d4b5a7)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103.jar(SHA1: bf0c54f15a4d94743c9c0ff0344b0e6248f0cb3b)/org/apache/tomcat/tomcat-util/7.0.103/tomcat-util-7.0.103.jar.asc(SHA1: 67cfe8faeb99ea3efe84557782b9ffa5953c5ff0)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103-sources.jar(SHA1: f76f4c07f89739d331d88beb20ec0f6af9fd6548)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103.pom(SHA1: 1ff6f075ad0a49accc62451f48b1e8f03c068d84)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103-sources.jar.asc(SHA1: a64928a836ff56c62ba0ae26263d72bd5d322e87)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103.jar(SHA1: b81203ac194a9922600fd6c253d862fd31747fc5)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103.jar.asc(SHA1: e8f4b61ebd444c3bc2612cd0fa91689c34780652)/org/apache/tomcat/tomcat-catalina/7.0.103/tomcat-catalina-7.0.103.pom.asc(SHA1: 3a5371fad44b2c95cb4afb852358adbe2613)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103.jar.asc(SHA1: e42f694d320ef5ae78ac8c85f4e26cb37a804746)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103-sources.jar(SHA1: 75639161248db25419b3cdae99cc43fb33bb0060)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103.jar(SHA1: 2594f4266237d17ad217026d331108f5c9f7c8da)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103.pom.asc(SHA1: f158a5cba575c5a66f64dfb5b3eea18dfe42)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103-sources.jar.asc(SHA1: 1dbbb6e7fff14a631bb21f67d9caba3d99db2f9d)/org/apache/tomcat/tomcat-catalina-ws/7.0.103/tomcat-catalina-ws-7.0.103.pom(SHA1: 80a080e3b375958446dbdd02cda3845ca3c397f4)/org/apache/tomcat/tomcat-i18n-fr/7.0.103/tomcat-i18n-fr-7.0.103.pom(SHA1: 8dce8a6d1f410411eae7af540e0f3f9141094554)/org/apache/tomcat/tomcat-i18n-fr/7.0.103/tomcat-i18n-fr-7.0.103.jar(SHA1: 4df971cc5823720565dab4bffab8b4eb51836357)/org/apache/tomcat/tomcat-i18n-fr/7.0.103/tomcat-i18n-fr-7.0.103.jar.asc(SHA1: 0d3816854954b02d785e130c2f6674cad8bb95d8)/org/apache/tomcat/tomcat-i18n-fr/7.0.103/tomcat-i18n-fr-7.0.103.pom.asc(SHA1: a5a9f30fd0fed44507f6cd9339e14244bb13f1cd)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103.pom(SHA1: 35f1e5b22917f238ffeab1f73750138698304780)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103-sources.jar(SHA1: b0b5f1b83808c158073bdcaa4f1c1928ad3a7632)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103.jar(SHA1: c78e0666b5de99cb6ca0c5193232ccf536044688)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103-sources.jar.asc(SHA1: 34e952edcaaab97423df90d38fb763536fc8bb80)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103.jar.asc(SHA1: 055498cd188952b6408d8af5720cad4db1717ae6)/org/apache/tomcat/tomcat-jdbc/7.0.103/tomcat-jdbc-7.0.103.pom.asc(SHA1: 13f13ef19563b79c996dedf23576bc1bf4d23fb2)/org/apache/tomcat/embed/tomcat-embed-logging-log4j/7.0.103/tomcat-embed-logging-log4j-7.0.103.jar.asc(SHA1: a597709f50224dc3e8061581d9c2b1ec60c199dd)/org/apache/tomcat/embed/tomcat-embed-logging-log4j/7.0.103/tomca
svn commit: r38563 - /dev/tomcat/tomcat-7/v7.0.103/ /release/tomcat/tomcat-7/v7.0.103/
Author: violetagg Date: Thu Mar 19 17:19:30 2020 New Revision: 38563 Log: Release Tomcat 7.0.103 Added: release/tomcat/tomcat-7/v7.0.103/ - copied from r38562, dev/tomcat/tomcat-7/v7.0.103/ Removed: dev/tomcat/tomcat-7/v7.0.103/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 7.0.x updated: Update Tomcat 7.0.103 release date
This is an automated email from the ASF dual-hosted git repository. violetagg pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/7.0.x by this push: new 2c343f5 Update Tomcat 7.0.103 release date 2c343f5 is described below commit 2c343f506bac03b9f0f40a159262b3348233479d Author: Violeta Georgieva AuthorDate: Thu Mar 19 19:25:01 2020 +0200 Update Tomcat 7.0.103 release date --- webapps/docs/changelog.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 2ac611c..8f00b1a 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -70,7 +70,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Add a test case for BZ64240
On 19/03/2020 13:49, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> remm 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 c870a1e Add a test case for BZ64240
> c870a1e is described below
>
> commit c870a1ea7f09b885ff724702562b3e1df14ff06e
> Author: remm
> AuthorDate: Thu Mar 19 14:49:21 2020 +0100
>
> Add a test case for BZ64240
There is a test for this already in TestHttp11InputBufferCRLF.
I have some patches for that class that will trigger some failures but
not the one described in BZ 64240.
Mark
>
> I couldn't reproduce it, so tried a test case (with some sleeps to see
> if there would be some state problem when going to the poller). Works
> for me.
> ---
> .../coyote/http11/TestHttp11InputBuffer.java | 45
> ++
> 1 file changed, 45 insertions(+)
>
> diff --git a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
> b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
> index a1d50d0..c9204a2 100644
> --- a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
> +++ b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
> @@ -17,8 +17,15 @@
>
> package org.apache.coyote.http11;
>
> +import java.io.BufferedReader;
> import java.io.IOException;
> +import java.io.InputStream;
> +import java.io.InputStreamReader;
> +import java.io.OutputStream;
> +import java.io.OutputStreamWriter;
> import java.io.PrintWriter;
> +import java.io.Writer;
> +import java.net.Socket;
> import java.util.Enumeration;
>
> import jakarta.servlet.ServletException;
> @@ -656,6 +663,44 @@ public class TestHttp11InputBuffer extends
> TomcatBaseTest {
>
>
> @Test
> +public void testValidHttp09() throws Exception {
> +
> +Tomcat tomcat = getTomcatInstance();
> +
> +tomcat.addContext("", TEMP_DIR);
> +tomcat.start();
> +
> +Socket socket = null;
> +OutputStream os = null;
> +InputStream is = null;
> +BufferedReader reader = null;
> +Writer writer = null;
> +final String encoding = "ISO-8859-1";
> +
> +for (int i = 0; i < 10; i++) {
> +socket = new Socket("localhost", getPort());
> +os = socket.getOutputStream();
> +writer = new OutputStreamWriter(os, encoding);
> +writer.write("GET /");
> +writer.flush();
> +Thread.sleep(10);
> +writer.write(CR);
> +writer.flush();
> +Thread.sleep(10);
> +writer.write(LF);
> +writer.flush();
> +is = socket.getInputStream();
> +reader = new BufferedReader(new InputStreamReader(is));
> +String line = reader.readLine();
> +Assert.assertNotNull(line);
> +Assert.assertTrue(line.indexOf("404") != -1);
> +socket.close();
> +}
> +
> +}
> +
> +
> +@Test
> public void testInvalidHttp09() {
>
> String[] request = new String[1];
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Allow multiple property sources
This is an automated email from the ASF dual-hosted git repository.
remm 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 9730818 Allow multiple property sources
9730818 is described below
commit 9730818c0df0fda5b4106de4b1a409b036899334
Author: remm
AuthorDate: Thu Mar 19 18:31:33 2020 +0100
Allow multiple property sources
The problem appears with the introduction of EnvironmentPropertySource,
where people could use it but prevent use of a custom property source.
---
java/org/apache/tomcat/util/digester/Digester.java | 76 +-
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/systemprops.xml| 3 +-
3 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index 46d80d0..6b0d1f7 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -25,6 +25,7 @@ import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
import java.security.Permission;
+import java.util.ArrayList;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.List;
@@ -32,6 +33,7 @@ import java.util.Map;
import java.util.Properties;
import java.util.PropertyPermission;
import java.util.Set;
+import java.util.StringTokenizer;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
@@ -84,31 +86,36 @@ public class Digester extends DefaultHandler2 {
// -- Static Fields
-protected static IntrospectionUtils.PropertySource propertySource;
-private static boolean propertySourceSet = false;
+protected static IntrospectionUtils.PropertySource[] propertySources;
+private static boolean propertySourcesSet = false;
protected static final StringManager sm =
StringManager.getManager(Digester.class);
static {
-String className =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
-IntrospectionUtils.PropertySource source = null;
-if (className != null) {
-ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
-Thread.currentThread().getContextClassLoader() };
-for (int i = 0; i < cls.length; i++) {
-try {
-Class clazz = Class.forName(className, true, cls[i]);
-source = (IntrospectionUtils.PropertySource)
-clazz.getConstructor().newInstance();
-break;
-} catch (Throwable t) {
-ExceptionUtils.handleThrowable(t);
-
LogFactory.getLog(Digester.class).error(sm.getString("digester.propertySourceLoadError",
className), t);
+String classNames =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
+ArrayList sourcesList = new
ArrayList<>();
+IntrospectionUtils.PropertySource[] sources = null;
+if (classNames != null) {
+StringTokenizer classNamesTokenizer = new
StringTokenizer(classNames, ",");
+while (classNamesTokenizer.hasMoreTokens()) {
+String className = classNamesTokenizer.nextToken().trim();
+ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
+Thread.currentThread().getContextClassLoader() };
+for (int i = 0; i < cls.length; i++) {
+try {
+Class clazz = Class.forName(className, true,
cls[i]);
+sourcesList.add((IntrospectionUtils.PropertySource)
clazz.getConstructor().newInstance());
+break;
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+
LogFactory.getLog(Digester.class).error(sm.getString("digester.propertySourceLoadError",
className), t);
+}
}
}
+sources = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
}
-if (source != null) {
-propertySource = source;
-propertySourceSet = true;
+if (sources != null) {
+propertySources = sources;
+propertySourcesSet = true;
}
if
(Boolean.getBoolean("org.apache.tomcat.util.digester.REPLACE_SYSTEM_PROPERTIES"))
{
replaceSystemProperties();
@@ -116,9 +123,17 @@ public class Digester extends DefaultHandler2 {
}
public static void setPropertySource(IntrospectionUtils.PropertySource
propertySource) {
-if (!propertySourceSet
[tomcat] branch master updated: Revert as relevant tests are already present in another class
This is an automated email from the ASF dual-hosted git repository.
remm 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 47afb7c Revert as relevant tests are already present in another class
47afb7c is described below
commit 47afb7cfe31922c57af0594a696dc5c38e3ea716
Author: remm
AuthorDate: Thu Mar 19 18:33:52 2020 +0100
Revert as relevant tests are already present in another class
---
.../coyote/http11/TestHttp11InputBuffer.java | 45 --
1 file changed, 45 deletions(-)
diff --git a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
index c9204a2..a1d50d0 100644
--- a/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
+++ b/test/org/apache/coyote/http11/TestHttp11InputBuffer.java
@@ -17,15 +17,8 @@
package org.apache.coyote.http11;
-import java.io.BufferedReader;
import java.io.IOException;
-import java.io.InputStream;
-import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
import java.io.PrintWriter;
-import java.io.Writer;
-import java.net.Socket;
import java.util.Enumeration;
import jakarta.servlet.ServletException;
@@ -663,44 +656,6 @@ public class TestHttp11InputBuffer extends TomcatBaseTest {
@Test
-public void testValidHttp09() throws Exception {
-
-Tomcat tomcat = getTomcatInstance();
-
-tomcat.addContext("", TEMP_DIR);
-tomcat.start();
-
-Socket socket = null;
-OutputStream os = null;
-InputStream is = null;
-BufferedReader reader = null;
-Writer writer = null;
-final String encoding = "ISO-8859-1";
-
-for (int i = 0; i < 10; i++) {
-socket = new Socket("localhost", getPort());
-os = socket.getOutputStream();
-writer = new OutputStreamWriter(os, encoding);
-writer.write("GET /");
-writer.flush();
-Thread.sleep(10);
-writer.write(CR);
-writer.flush();
-Thread.sleep(10);
-writer.write(LF);
-writer.flush();
-is = socket.getInputStream();
-reader = new BufferedReader(new InputStreamReader(is));
-String line = reader.readLine();
-Assert.assertNotNull(line);
-Assert.assertTrue(line.indexOf("404") != -1);
-socket.close();
-}
-
-}
-
-
-@Test
public void testInvalidHttp09() {
String[] request = new String[1];
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-7-trunk/builds/1644 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' triggered this build Build Source Stamp: [branch 7.0.x] 2c343f506bac03b9f0f40a159262b3348233479d Blamelist: Violeta Georgieva Build succeeded! Sincerely, -The Buildbot - 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: Allow multiple property sources
This is an automated email from the ASF dual-hosted git repository.
remm 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 7ecda7d Allow multiple property sources
7ecda7d is described below
commit 7ecda7d462bcebba0c07a088af5cd5bcf46978b0
Author: remm
AuthorDate: Thu Mar 19 18:31:33 2020 +0100
Allow multiple property sources
The problem appears with the introduction of EnvironmentPropertySource,
where people could use it but prevent use of a custom property source.
---
java/org/apache/tomcat/util/digester/Digester.java | 76 +-
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/systemprops.xml| 3 +-
3 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index fcf32c7..9fd4a15 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -25,6 +25,7 @@ import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
import java.security.Permission;
+import java.util.ArrayList;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.List;
@@ -32,6 +33,7 @@ import java.util.Map;
import java.util.Properties;
import java.util.PropertyPermission;
import java.util.Set;
+import java.util.StringTokenizer;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
@@ -84,31 +86,36 @@ public class Digester extends DefaultHandler2 {
// -- Static Fields
-protected static IntrospectionUtils.PropertySource propertySource;
-private static boolean propertySourceSet = false;
+protected static IntrospectionUtils.PropertySource[] propertySources;
+private static boolean propertySourcesSet = false;
protected static final StringManager sm =
StringManager.getManager(Digester.class);
static {
-String className =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
-IntrospectionUtils.PropertySource source = null;
-if (className != null) {
-ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
-Thread.currentThread().getContextClassLoader() };
-for (int i = 0; i < cls.length; i++) {
-try {
-Class clazz = Class.forName(className, true, cls[i]);
-source = (IntrospectionUtils.PropertySource)
-clazz.getConstructor().newInstance();
-break;
-} catch (Throwable t) {
-ExceptionUtils.handleThrowable(t);
-
LogFactory.getLog(Digester.class).error(sm.getString("digester.propertySourceLoadError",
className), t);
+String classNames =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
+ArrayList sourcesList = new
ArrayList<>();
+IntrospectionUtils.PropertySource[] sources = null;
+if (classNames != null) {
+StringTokenizer classNamesTokenizer = new
StringTokenizer(classNames, ",");
+while (classNamesTokenizer.hasMoreTokens()) {
+String className = classNamesTokenizer.nextToken().trim();
+ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
+Thread.currentThread().getContextClassLoader() };
+for (int i = 0; i < cls.length; i++) {
+try {
+Class clazz = Class.forName(className, true,
cls[i]);
+sourcesList.add((IntrospectionUtils.PropertySource)
clazz.getConstructor().newInstance());
+break;
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+
LogFactory.getLog(Digester.class).error(sm.getString("digester.propertySourceLoadError",
className), t);
+}
}
}
+sources = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
}
-if (source != null) {
-propertySource = source;
-propertySourceSet = true;
+if (sources != null) {
+propertySources = sources;
+propertySourcesSet = true;
}
if
(Boolean.getBoolean("org.apache.tomcat.util.digester.REPLACE_SYSTEM_PROPERTIES"))
{
replaceSystemProperties();
@@ -116,9 +123,17 @@ public class Digester extends DefaultHandler2 {
}
public static void setPropertySource(IntrospectionUtils.PropertySource
propertySource) {
-if (!propertySourceSet)
[Bug 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #11 from Christopher Schultz --- (In reply to Michael Osipov from comment #5) > (In reply to Remy Maucherat from comment #4) > > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > > still have it (clients which insist would still get something back). > > +1 for this in Tomcat 10. -1 for this in Tomcat 10. There are a huge number of stupid devices in the world that nobody can change. Sure, you can tell everyone using NoName-brand WiFi light bulbs that HTTP/0.9 is dead, but you can't tell F5 that HTTP/0.9 is dead and they had better upgrade. -- 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: Allow multiple property sources
This is an automated email from the ASF dual-hosted git repository.
remm 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 8adb6e1 Allow multiple property sources
8adb6e1 is described below
commit 8adb6e10065c93d93de584bb5cb0648dc30f1597
Author: remm
AuthorDate: Thu Mar 19 18:31:33 2020 +0100
Allow multiple property sources
The problem appears with the introduction of EnvironmentPropertySource,
where people could use it but prevent use of a custom property source.
---
java/org/apache/tomcat/util/digester/Digester.java | 74 ++
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/systemprops.xml| 3 +-
3 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index 9326ba4..ec0e256 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -25,6 +25,7 @@ import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
import java.security.Permission;
+import java.util.ArrayList;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.List;
@@ -32,6 +33,7 @@ import java.util.Map;
import java.util.Properties;
import java.util.PropertyPermission;
import java.util.Set;
+import java.util.StringTokenizer;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParser;
@@ -84,32 +86,37 @@ public class Digester extends DefaultHandler2 {
// -- Static Fields
-protected static IntrospectionUtils.PropertySource propertySource;
-private static boolean propertySourceSet = false;
+protected static IntrospectionUtils.PropertySource[] propertySources;
+private static boolean propertySourcesSet = false;
protected static final StringManager sm =
StringManager.getManager(Digester.class);
static {
-String className =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
-IntrospectionUtils.PropertySource source = null;
-if (className != null) {
-ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
-Thread.currentThread().getContextClassLoader() };
-for (int i = 0; i < cls.length; i++) {
-try {
-Class clazz = Class.forName(className, true, cls[i]);
-source = (IntrospectionUtils.PropertySource)
-clazz.getConstructor().newInstance();
-break;
-} catch (Throwable t) {
-ExceptionUtils.handleThrowable(t);
+String classNames =
System.getProperty("org.apache.tomcat.util.digester.PROPERTY_SOURCE");
+ArrayList sourcesList = new
ArrayList<>();
+IntrospectionUtils.PropertySource[] sources = null;
+if (classNames != null) {
+StringTokenizer classNamesTokenizer = new
StringTokenizer(classNames, ",");
+while (classNamesTokenizer.hasMoreTokens()) {
+String className = classNamesTokenizer.nextToken().trim();
+ClassLoader[] cls = new ClassLoader[] {
Digester.class.getClassLoader(),
+Thread.currentThread().getContextClassLoader() };
+for (int i = 0; i < cls.length; i++) {
+try {
+Class clazz = Class.forName(className, true,
cls[i]);
+sourcesList.add((IntrospectionUtils.PropertySource)
clazz.getConstructor().newInstance());
+break;
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
LogFactory.getLog("org.apache.tomcat.util.digester.Digester")
.error("Unable to load property source[" +
className + "].", t);
+}
}
}
+sources = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
}
-if (source != null) {
-propertySource = source;
-propertySourceSet = true;
+if (sources != null) {
+propertySources = sources;
+propertySourcesSet = true;
}
if
(Boolean.getBoolean("org.apache.tomcat.util.digester.REPLACE_SYSTEM_PROPERTIES"))
{
replaceSystemProperties();
@@ -117,9 +124,17 @@ public class Digester extends DefaultHandler2 {
}
public static void setPropertySource(IntrospectionUtils.PropertySource
propertySource) {
-if (!propertySourceSet) {
-Digester.propertySource = propertySource;
-propertySou
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #6 from Em Domingues --- I assume this was intentional, but in the event it wasn't, the combination of the patch for this issue and the previous "strict header value parsing" commit have resulted in Tomcat rejecting all requests that use a single LF as a delimiter between HTTP request lines as opposed to the correct delimiter of CRLF. Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3) it is recommended that applications be tolerant of malformed requests, with HTTP header delimiters called out as a particular area of note: > The line terminator for message-header fields is the sequence CRLF. > However, we recommend that applications, when parsing such headers, > recognize a single LF as a line terminator and ignore the leading CR. After deploying Tomcat 8.5.53 in our environment, we noticed that our hardware load balancers were sending malformed requests of the following format to perform host liveness checks against our app servers: GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n We are able to correct these requests (thankfully) but this behavior wasn't called out in the Tomcat release notes. It also represents a stricter interpretation of RFC 2616 than other major web server software, so I figured I'd at least flag it 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #12 from Michael Osipov --- (In reply to Christopher Schultz from comment #11) > (In reply to Michael Osipov from comment #5) > > (In reply to Remy Maucherat from comment #4) > > > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > > > still have it (clients which insist would still get something back). > > > > +1 for this in Tomcat 10. > > -1 for this in Tomcat 10. > > There are a huge number of stupid devices in the world that nobody can > change. Sure, you can tell everyone using NoName-brand WiFi light bulbs that > HTTP/0.9 is dead, but you can't tell F5 that HTTP/0.9 is dead and they had > better upgrade. This is the same discussion as with the dropped reason phrase. HTTP/1.1. has been introduced almost 21 years ago. If F5 Networks did not manage to update their code in 21 years, they won't do it ever. -- 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 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #7 from Michael Osipov --- (In reply to Em Domingues from comment #6) > I assume this was intentional, but in the event it wasn't, the combination > of the patch for this issue and the previous "strict header value parsing" > commit have resulted in Tomcat rejecting all requests that use a single LF > as a delimiter between HTTP request lines as opposed to the correct > delimiter of CRLF. > > Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3) > it is recommended that applications be tolerant of malformed requests, with > HTTP header delimiters called out as a particular area of note: > > The line terminator for message-header fields is the sequence CRLF. > > However, we recommend that applications, when parsing such headers, > > recognize a single LF as a line terminator and ignore the leading CR. > > After deploying Tomcat 8.5.53 in our environment, we noticed that our > hardware load balancers were sending malformed requests of the following > format to perform host liveness checks against our app servers: > GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n > > We are able to correct these requests (thankfully) but this behavior wasn't > called out in the Tomcat release notes. It also represents a stricter > interpretation of RFC 2616 than other major web server software, so I > figured I'd at least flag it here. I can't find similar in https://tools.ietf.org/html/rfc7230#section-3.1.1 RFC 2616 is obsolete. -- 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 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #8 from Em Domingues --- (In reply to Michael Osipov from comment #7) > (In reply to Em Domingues from comment #6) > > I assume this was intentional, but in the event it wasn't, the combination > > of the patch for this issue and the previous "strict header value parsing" > > commit have resulted in Tomcat rejecting all requests that use a single LF > > as a delimiter between HTTP request lines as opposed to the correct > > delimiter of CRLF. > > > > Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3) > > it is recommended that applications be tolerant of malformed requests, with > > HTTP header delimiters called out as a particular area of note: > > > The line terminator for message-header fields is the sequence CRLF. > > > However, we recommend that applications, when parsing such headers, > > > recognize a single LF as a line terminator and ignore the leading CR. > > > > After deploying Tomcat 8.5.53 in our environment, we noticed that our > > hardware load balancers were sending malformed requests of the following > > format to perform host liveness checks against our app servers: > > GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n > > > > We are able to correct these requests (thankfully) but this behavior wasn't > > called out in the Tomcat release notes. It also represents a stricter > > interpretation of RFC 2616 than other major web server software, so I > > figured I'd at least flag it here. > > I can't find similar in https://tools.ietf.org/html/rfc7230#section-3.1.1 > > RFC 2616 is obsolete. I'm aware. This still runs counter to the robustness principle, no? For example, the implementation is inconsistent in where it errs on the side of being strict (here) and where it errs on the side of being tolerant (allowing multiple SP or HT between tokens) even when that's similarly against spec: https://github.com/apache/tomcat/blob/ae8c82eff96990878e79691819ae941538ee62fd/java/org/apache/coyote/http11/Http11InputBuffer.java#L404 -- 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 63691] Add a no-op JarScanner
https://bz.apache.org/bugzilla/show_bug.cgi?id=63691 --- Comment #10 from quaff --- (In reply to Joshua Lipstone from comment #8) > Can you please either undo this or change it so that the Jars are only > scanned if they match the inclusion filter. > As of 9.0.30, if you wanted to set the logic so that it only scans a short > list of jars, you could do: > jarsToSkip=* > jarsToScan=jar1.jar,jar2.jar > As of 9.0.31, this now causes cascading startup failures. I have encounter the same problem, Tomcat breaks back compatibility. -- 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 64247] New: no-op JarScanner breaks back compatibility
https://bz.apache.org/bugzilla/show_bug.cgi?id=64247 Bug ID: 64247 Summary: no-op JarScanner breaks back compatibility Product: Tomcat 9 Version: 9.0.31 Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: zhouyanm...@gmail.com Target Milestone: - please see https://bz.apache.org/bugzilla/show_bug.cgi?id=63691#c10 -- 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 64247] no-op JarScanner breaks back compatibility
https://bz.apache.org/bugzilla/show_bug.cgi?id=64247 --- Comment #1 from quaff --- If it's a designed feature, It should be targeted at tomcat 10, add a warning in upgrade guide. -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #13 from dingli <382188...@qq.com> --- (In reply to Michael Osipov from comment #12) > (In reply to Christopher Schultz from comment #11) > > (In reply to Michael Osipov from comment #5) > > > (In reply to Remy Maucherat from comment #4) > > > > Why is 0.9 support not removed by now ? It sounds *quite* ridiculous to > > > > still have it (clients which insist would still get something back). > > > > > > +1 for this in Tomcat 10. > > > > -1 for this in Tomcat 10. > > > > There are a huge number of stupid devices in the world that nobody can > > change. Sure, you can tell everyone using NoName-brand WiFi light bulbs that > > HTTP/0.9 is dead, but you can't tell F5 that HTTP/0.9 is dead and they had > > better upgrade. > > This is the same discussion as with the dropped reason phrase. HTTP/1.1. has > been introduced almost 21 years ago. If F5 Networks did not manage to update > their code in 21 years, they won't do it ever. F5 can send HTTP/1.0 or HTTP/1.1 request in http monitor. but ths stupid thing is the default setting is HTTP/0.9 we have change the F5 setting last night,now it works for tomcat 8.5.53 -- 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 64240] http 0.9 request return nothing
https://bz.apache.org/bugzilla/show_bug.cgi?id=64240 --- Comment #14 from dingli <382188...@qq.com> --- (In reply to Remy Maucherat from comment #10) > I fail to see the problem so I added a test case to test HTTP/0.9 support > (using "GET /CRLF"), and it works for me. yesterday I can reproduce the bug in my local windows machine and local Ubuntu VM sometime(NOT everytime) but I can't reproduce it today :( maybe it is related with some corner case ? such as uninitialized variable or memory? But for tomcat 8.5.51, I can reproduce it everytime tomcat 8.5.51 won't send content for "GET /CRLF" same as 8.5.53 the difference is 8.5.53 will close the socket immediately 8.5.51 will keep the socket open and close the socket after 20 seconds below is the tomcat 8.5.51 catalina log: 20-Mar-2020 13:13:37.718 FINE [http-nio-8080-exec-3] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Processing socket [org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]] with status [OPEN_READ] 20-Mar-2020 13:13:37.719 FINE [http-nio-8080-exec-3] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Found processor [null] for socket [org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]] 20-Mar-2020 13:13:37.719 FINE [http-nio-8080-exec-3] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Popped processor [org.apache.coyote.http11.Http11Processor@2d8c7e6c] from cache 20-Mar-2020 13:13:37.719 FINE [http-nio-8080-exec-3] org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [GET /^M ] 20-Mar-2020 13:13:37.725 FINE [http-nio-8080-exec-3] org.apache.coyote.AbstractProcessorLight.process Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@3eced8ba:org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]], Status in: [OPEN_READ], State out: [LONG] 20-Mar-2020 13:13:57.751 FINE [http-nio-8080-exec-4] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Processing socket [org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]] with status [ERROR] 20-Mar-2020 13:13:57.751 FINE [http-nio-8080-exec-4] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Found processor [org.apache.coyote.http11.Http11Processor@2d8c7e6c] for socket [org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]] 20-Mar-2020 13:13:57.751 FINE [http-nio-8080-exec-4] org.apache.coyote.AbstractProtocol.removeWaitingProcessor Removed processor [org.apache.coyote.http11.Http11Processor@2d8c7e6c] from waiting processors 20-Mar-2020 13:13:57.752 FINE [http-nio-8080-exec-4] org.apache.coyote.AbstractProcessorLight.process Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@3eced8ba:org.apache.tomcat.util.net.NioChannel@6fc5100f:java.nio.channels.SocketChannel[connected local=/192.168.31.50:8080 remote=/192.168.31.6:51783]], Status in: [ERROR], State out: [CLOSED] 20-Mar-2020 13:13:57.753 FINE [http-nio-8080-exec-4] org.apache.coyote.AbstractProtocol$ConnectionHandler.release Pushed Processor [org.apache.coyote.http11.Http11Processor@2d8c7e6c] -- 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
