Re: mod_headers as a Filter
On 27/04/2021 22:14, Rémy Maucherat wrote: I remember after doing the rewrite valve I got asked a bit about mod_headers because "why not". However, now I recall I found out it would be far less practical. So I very quickly moved on since it was also less useful than rewrite. I would still probably not do it. I'm rapidly coming to the same conclusion. Certainly for a pure Filter approach. And a Valve approach doesn't look much better. I'm currently mulling over an extension point for the Connector. responseHeaderValidationClass or similar. Ideas at this point are: - have one or more callbacks from AbstractProcessor.prepareResponse() - provide a number of standard implementations - NO-OP (same as now) - warn (logs a warning for anything dangerous it finds) - fix (removes/fixes any invalid headers) Alternatively, configuration could be nested inside the connector element which would allow the option for more configuration. We could still have standard implementations. My expectation is that a suitable default would be added (probably not NO-OP) if no explicit configuration was provided. I'm wondering if there is merit in a Valve-like mechanism for Coyote. Name TBD but would look something like: - callbacks - after request headers are parsed / before the request is prepared - after the request is prepared - before response headers are prepared - after response headers are prepared / before they are written - allow multiple "Valves" to be configured - provide a "default" that doesn't require explicit config - explicit config can add custom "valves", the default "valve" or any combination I'm leaning towards the latter approach as it has much greater flexibility and I can see different users having subtly different requirements and this avoids an explosion of configuration attributes on a single class. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #3 from Mark Thomas --- Section 3.1.7 of the WebSocket specification requires endpoint instances are created via ServerEndpointConfig.Configurator.getEndpointInstance(). Users are free to supply their own Configurator implementation. Therefore, it is not possible to use the InstanceManager to create the endpoint. The current call to InstanceManager.newInstance(Object) is the best that can be achieved. I'll spend a little more time looking at the encoders and decoders but, given that there is no specification requirement for these to support DI, whether anything gets implemented is going to depend a lot on how cleanly it can be done. -- 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 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #4 from romain.manni-bucau --- @Mark: this issue is about the default configurator, fully agree when a custom configurator is used tomcat will not care. I also agree encoders/decoders IoC support is not in the specification but not having it lead to very weird patterns - even for just a plain JSON codec when you want to do it right and consistent with app code/config, makes it not natural at all and lead to easy leaks so I think it is worth going through the InstanceManager anyway and make it to the spec at some point. -- 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: mod_headers as a Filter
On Wed, Apr 28, 2021 at 9:07 AM Mark Thomas wrote: > I'm wondering if there is merit in a Valve-like mechanism for Coyote. > Name TBD but would look something like: > - callbacks >- after request headers are parsed / before the request is prepared >- after the request is prepared >- before response headers are prepared >- after response headers are prepared / before they are written > - allow multiple "Valves" to be configured > - provide a "default" that doesn't require explicit config > - explicit config can add custom "valves", the default "valve" or any >combination > I thought about it quite a bit in the past, an interceptor [resurrecting the old name] could be a solution to a lot of problems here. So why not. Rémy > > I'm leaning towards the latter approach as it has much greater > flexibility and I can see different users having subtly different > requirements and this avoids an explosion of configuration attributes on > a single class. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #5 from Remy Maucherat --- (In reply to romain.manni-bucau from comment #4) > @Mark: this issue is about the default configurator, fully agree when a > custom configurator is used tomcat will not care. I agree if using the default configurator then we know what it does and instead of complying 100% with the specification, we could shortcut to the instance manager to create the instance and solve your problem. There are shortcuts for IO as well, so why not. -- 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 65272] New: Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272
Bug ID: 65272
Summary: Problems proccessing HTTP request without CR in last
versions
Product: Tomcat 9
Version: 9.0.x
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: miguelinh...@gmail.com
Target Milestone: -
With last versions of Apache Tomcat 9, we have problems to process http request
created by legacy systems that haven't separating the sections of a HTTP
Request, having only a LF as delimeter.
The error returned by Tomcat is:
java.lang.IllegalArgumentException: Invalid character found in the HTTP
protocol [HTTP/1.00x0aUser-Agent:]
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:559)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:261)
This request fails in Apache Tomcat 9.0.45, 9.0.41 but works in Apache Tomcat
9.0.26 or in Apache Tomcat 7.
POST /sms/feedback HTTP/1.0[LF]
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)[LF]
Host: 10.252.12.1[LF]
Proxy-Connection: Keep-Alive[LF]
Content-Type: text/xml; charset=utf-8[LF]
Content-Length: 308[LF]
[LF]
[LF]
[LF]
2[LF]
R[LF]
666111222[LF]
270421133100[LF]
270421133100[LF]
17913195f9388ee6b37de829cba3[LF]
El mensaje enviado al numero 666111222 ha sido entregado el 27.04.21
13:31:00[LF]
[LF]
This request works:
POST /sms/feedback HTTP/1.0[CRLF]
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)[CRLF]
Host: 10.252.12.1[CRLF]
Proxy-Connection: Keep-Alive[CRLF]
Content-Type: text/xml; charset=utf-8[CRLF]
Content-Length: 308[CRLF]
[CRLF]
[CRLF]
[CRLF]
2[CRLF]
R[CRLF]
666111222[CRLF]
270421133100[CRLF]
270421133100[CRLF]
17913195f9388ee6b37de829cba3[CRLF]
El mensaje enviado al numero 666111222 ha sido entregado el 27.04.21
13:31:00[CRLF]
[CRLF]
You can test this using this java code (supossing tha Tomcat is running on 8080
port at localhost):
The mensaje2 variable works fine (CRLF is represented by 13,10 codes).
The mensaje2 fails (LF is represented by 10 code)
int[] mensaje2 =
{80,79,83,84,32,47,115,109,115,47,102,101,101,100,98,97,99,107,32,72,84,84,80,47,49,46,48,13,10,85,115,101,114,45,65,103,101,110,116,58,32,77,111,122,105,108,108,97,47,52,46,48,32,40,99,111,109,112,97,116,105,98,108,101,59,32,77,83,73,69,32,
53,46,48,59,32,87,105,110,100,111,119,115,32,57,56,59,32,68,105,103,69,120,116,41,13,10,72,111,115,116,58,32,49,48,46,50,53,50,46,49,50,46,49,13,10,80,114,111,120,121,45,67,111,110,110,101,99,116,105,111,110,58,32,75,101,101,112,45,65,108,105,
118,101,13,10,67,111,110,116,101,110,116,45,84,121,112,101,58,32,116,101,120,116,47,120,109,108,59,32,99,104,97,114,115,101,116,61,117,116,102,45,56,13,10,67,111,110,116,101,110,116,45,76,101,110,103,116,104,58,32,51,48,56,13,10,13,10,60,63,120,109,
108,32,118,101,114,115,105,111,110,61,34,49,46,48,34,32,101,110,99,111,100,105,110,103,61,34,85,84,70,45,56,34,63,62,13,10,60,82,69,83,80,85,69,83,84,65,62,10,60,84,73,80,79,62,50,60,47,84,73,80,79,62,10,60,65,68,67,62,82,60,47,65,68,67,62,
10,60,79,65,68,67,62,54,55,55,50,50,50,53,54,50,60,47,79,65,68,67,62,10,60,83,67,84,83,62,50,55,48,52,50,49,49,51,51,49,48,48,60,47,83,67,84,83,62,10,60,68,83,67,84,83,62,50,55,48,52,50,49,49,51,51,49,48,48,60,47,68,83,67,84,83,62,10,60,
73,68,77,83,71,62,49,55,57,49,51,49,57,53,102,57,51,48,48,48,48,56,56,101,101,54,98,51,55,100,101,56,50,57,99,98,97,51,60,47,73,68,77,83,71,62,10,60,65,77,83,71,62,69,108,32,109,101,110,115,97,106,101,32,101,110,118,105,97,100,111,32,97,
108,32,110,117,109,101,114,111,32,54,55,55,50,50,50,53,54,50,32,104,97,32,115,105,100,111,32,101,110,116,114,101,103,97,100,111,32,101,108,32,50,55,46,48,52,46,50,49,32,49,51,58,51,49,58,48,48,60,47,65,77,83,71,62,10,60,47,82,69,83,80,85
,69,83,84,65,62};
int[] mensaje =
{80,79,83,84,32,47,115,109,115,47,102,101,101,100,98,97,99,107,32,72,84,84,80,47,49,46,48,10,85,115,101,114,45,65,103,101,110,116,58,32,77,111,122,105,108,108,97,47,52,46,48,32,40,99,111,109,112,97,116,105,98,108,101,59,32,77,83,73,69,32,
53,46,48,59,32,87,105,110,100,111,119,115,32,57,56,59,32,68,105,103,69,120,116,41,10,72,111,115,116,58,32,49,48,46,50,53,50,46,49,50,46,49,10,80,114,111,120,121,45,67,111,110,110,101,99,116,105,111,110,58,32,75,101,101,112,45,65,108,105,
118,101,10,67,111,110,116,101,110,116,45,84,121,112,101,58,32,116,101,120,116,47,120,109,108,59,32,99,104,97,114,115,101,116,61,117,116,102,45,56,10,67,111,110,116,101,110,116,45,76,101,110,103,116,104,58,32,51,48,56,10,10,60,63,120,109,
108,32,118,101,114,115,105,111,110,61,34,49,46,48,34,32,101,110,99,111,100,
[tomcat] branch master updated: Refactor system property source to be more flexible
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 c07530f Refactor system property source to be more flexible
c07530f is described below
commit c07530f6f11034ce0ba55a20d0ca058256a7509d
Author: remm
AuthorDate: Wed Apr 28 14:43:55 2021 +0200
Refactor system property source to be more flexible
Allows explicit use if desired.
---
java/org/apache/tomcat/util/digester/Digester.java | 44 ++-
.../tomcat/util/digester/SystemPropertySource.java | 51 ++
webapps/docs/changelog.xml | 5 +++
webapps/docs/config/systemprops.xml| 3 ++
4 files changed, 72 insertions(+), 31 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index 7c17eb9..9b943a5 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -24,16 +24,13 @@ import java.io.UnsupportedEncodingException;
import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
-import java.security.Permission;
import java.util.ArrayList;
-import java.util.Arrays;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Properties;
-import java.util.PropertyPermission;
import java.util.Set;
import java.util.StringTokenizer;
@@ -48,7 +45,6 @@ import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.IntrospectionUtils.PropertySource;
import org.apache.tomcat.util.buf.B2CConverter;
import org.apache.tomcat.util.res.StringManager;
-import org.apache.tomcat.util.security.PermissionCheck;
import org.xml.sax.Attributes;
import org.xml.sax.EntityResolver;
import org.xml.sax.ErrorHandler;
@@ -175,29 +171,7 @@ public class Digester extends DefaultHandler2 {
// --- Instance Variables
-private static class SystemPropertySource implements
IntrospectionUtils.SecurePropertySource {
-
-@Override
-public String getProperty(String key) {
-// For backward compatibility
-return getProperty(key, null);
-}
-
-@Override
-public String getProperty(String key, ClassLoader classLoader) {
-if (classLoader instanceof PermissionCheck) {
-Permission p = new PropertyPermission(key, "read");
-if (!((PermissionCheck) classLoader).check(p)) {
-return null;
-}
-}
-return System.getProperty(key);
-}
-}
-
-
-protected IntrospectionUtils.PropertySource[] source = new
IntrospectionUtils.PropertySource[] {
-new SystemPropertySource() };
+protected IntrospectionUtils.PropertySource[] source;
/**
@@ -381,12 +355,20 @@ public class Digester extends DefaultHandler2 {
public Digester() {
propertySourcesSet = true;
+ArrayList sourcesList = new
ArrayList<>();
+boolean systemPropertySourceFound = false;
if (propertySources != null) {
-ArrayList sourcesList = new
ArrayList<>();
-sourcesList.addAll(Arrays.asList(propertySources));
-sourcesList.add(source[0]);
-source = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
+for (IntrospectionUtils.PropertySource source : propertySources) {
+if (source instanceof SystemPropertySource) {
+systemPropertySourceFound = true;
+}
+sourcesList.add(source);
+}
+}
+if (!systemPropertySourceFound) {
+sourcesList.add(new SystemPropertySource());
}
+source = sourcesList.toArray(new IntrospectionUtils.PropertySource[0]);
}
diff --git a/java/org/apache/tomcat/util/digester/SystemPropertySource.java
b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
new file mode 100644
index 000..49fc765
--- /dev/null
+++ b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distri
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #6 from Mark Thomas --- @Rémy I think I can see a way to do that. We'll need to check which Configurator was used in the WsSession constructor to make sure we don't call the InstanceManager twice. It does mean that the timing of the call to InstanceManager will vary depending on the Configurator but I don't think that should be an issue. @Romain Do you need the InstanceManager to used used when testing the validity of the encoder/decoder classes (e.g. https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/Util.java#L345) or just when an Encoder/Decoder instance is created for an Endpoint? -- 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 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #7 from romain.manni-bucau --- @Mark functionally I can leave with current validation but theorically the validation is only known of the IoC but it is not super aligned on the spec. To illustrate it take a CDI or Spring encoder, it can use constructor injections and not have a default no-arg constrauctor but spec requires it so I guess validation can be let this way and we can ask the spec to drop this later moving the validation to the instantiation time only. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Refactor system property source to be more flexible
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 06eb5b1 Refactor system property source to be more flexible
06eb5b1 is described below
commit 06eb5b10d1c7852dac3d4022e45c3d28721dfd9a
Author: remm
AuthorDate: Wed Apr 28 14:43:55 2021 +0200
Refactor system property source to be more flexible
Allows explicit use if desired.
---
java/org/apache/tomcat/util/digester/Digester.java | 43 ++
.../tomcat/util/digester/SystemPropertySource.java | 51 ++
webapps/docs/changelog.xml | 5 +++
webapps/docs/config/systemprops.xml| 3 ++
4 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index 0b76684..12a72e4 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -24,16 +24,13 @@ import java.io.UnsupportedEncodingException;
import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
-import java.security.Permission;
import java.util.ArrayList;
-import java.util.Arrays;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Properties;
-import java.util.PropertyPermission;
import java.util.Set;
import java.util.StringTokenizer;
@@ -48,7 +45,6 @@ import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.IntrospectionUtils.PropertySource;
import org.apache.tomcat.util.buf.B2CConverter;
import org.apache.tomcat.util.res.StringManager;
-import org.apache.tomcat.util.security.PermissionCheck;
import org.xml.sax.Attributes;
import org.xml.sax.EntityResolver;
import org.xml.sax.ErrorHandler;
@@ -175,26 +171,6 @@ public class Digester extends DefaultHandler2 {
// --- Instance Variables
-private static class SystemPropertySource implements
IntrospectionUtils.SecurePropertySource {
-
-@Override
-public String getProperty(String key) {
-// For backward compatibility
-return getProperty(key, null);
-}
-
-@Override
-public String getProperty(String key, ClassLoader classLoader) {
-if (classLoader instanceof PermissionCheck) {
-Permission p = new PropertyPermission(key, "read");
-if (!((PermissionCheck) classLoader).check(p)) {
-return null;
-}
-}
-return System.getProperty(key);
-}
-}
-
/**
* A {@link org.apache.tomcat.util.IntrospectionUtils.SecurePropertySource}
* that uses environment variables to resolve expressions. Still available
@@ -208,8 +184,7 @@ public class Digester extends DefaultHandler2 {
}
-protected IntrospectionUtils.PropertySource[] source = new
IntrospectionUtils.PropertySource[] {
-new SystemPropertySource() };
+protected IntrospectionUtils.PropertySource[] source;
/**
@@ -393,12 +368,20 @@ public class Digester extends DefaultHandler2 {
public Digester() {
propertySourcesSet = true;
+ArrayList sourcesList = new
ArrayList<>();
+boolean systemPropertySourceFound = false;
if (propertySources != null) {
-ArrayList sourcesList = new
ArrayList<>();
-sourcesList.addAll(Arrays.asList(propertySources));
-sourcesList.add(source[0]);
-source = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
+for (IntrospectionUtils.PropertySource source : propertySources) {
+if (source instanceof SystemPropertySource) {
+systemPropertySourceFound = true;
+}
+sourcesList.add(source);
+}
+}
+if (!systemPropertySourceFound) {
+sourcesList.add(new SystemPropertySource());
}
+source = sourcesList.toArray(new IntrospectionUtils.PropertySource[0]);
}
diff --git a/java/org/apache/tomcat/util/digester/SystemPropertySource.java
b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
new file mode 100644
index 000..49fc765
--- /dev/null
+++ b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may
[tomcat] branch 8.5.x updated: Refactor system property source to be more flexible
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 2f9a206 Refactor system property source to be more flexible
2f9a206 is described below
commit 2f9a206d96d02f49abec2f8801fed6d7d8914f3d
Author: remm
AuthorDate: Wed Apr 28 14:43:55 2021 +0200
Refactor system property source to be more flexible
Allows explicit use if desired.
---
java/org/apache/tomcat/util/digester/Digester.java | 43 ++
.../tomcat/util/digester/SystemPropertySource.java | 51 ++
webapps/docs/changelog.xml | 5 +++
webapps/docs/config/systemprops.xml| 3 ++
4 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/java/org/apache/tomcat/util/digester/Digester.java
b/java/org/apache/tomcat/util/digester/Digester.java
index 2e941d0..cf455cf 100644
--- a/java/org/apache/tomcat/util/digester/Digester.java
+++ b/java/org/apache/tomcat/util/digester/Digester.java
@@ -24,15 +24,12 @@ import java.io.UnsupportedEncodingException;
import java.lang.reflect.InvocationTargetException;
import java.net.URI;
import java.net.URISyntaxException;
-import java.security.Permission;
import java.util.ArrayList;
-import java.util.Arrays;
import java.util.EmptyStackException;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;
-import java.util.PropertyPermission;
import java.util.Set;
import java.util.StringTokenizer;
@@ -47,7 +44,6 @@ import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.IntrospectionUtils.PropertySource;
import org.apache.tomcat.util.buf.B2CConverter;
import org.apache.tomcat.util.res.StringManager;
-import org.apache.tomcat.util.security.PermissionCheck;
import org.xml.sax.Attributes;
import org.xml.sax.EntityResolver;
import org.xml.sax.ErrorHandler;
@@ -142,26 +138,6 @@ public class Digester extends DefaultHandler2 {
// --- Instance Variables
-private static class SystemPropertySource implements
IntrospectionUtils.SecurePropertySource {
-
-@Override
-public String getProperty(String key) {
-// For backward compatibility
-return getProperty(key, null);
-}
-
-@Override
-public String getProperty(String key, ClassLoader classLoader) {
-if (classLoader instanceof PermissionCheck) {
-Permission p = new PropertyPermission(key, "read");
-if (!((PermissionCheck) classLoader).check(p)) {
-return null;
-}
-}
-return System.getProperty(key);
-}
-}
-
/**
* A {@link org.apache.tomcat.util.IntrospectionUtils.SecurePropertySource}
* that uses environment variables to resolve expressions. Still available
@@ -175,8 +151,7 @@ public class Digester extends DefaultHandler2 {
}
-protected IntrospectionUtils.PropertySource[] source = new
IntrospectionUtils.PropertySource[] {
-new SystemPropertySource() };
+protected IntrospectionUtils.PropertySource[] source;
/**
@@ -356,12 +331,20 @@ public class Digester extends DefaultHandler2 {
public Digester() {
propertySourcesSet = true;
+ArrayList sourcesList = new
ArrayList<>();
+boolean systemPropertySourceFound = false;
if (propertySources != null) {
-ArrayList sourcesList = new
ArrayList<>();
-sourcesList.addAll(Arrays.asList(propertySources));
-sourcesList.add(source[0]);
-source = sourcesList.toArray(new
IntrospectionUtils.PropertySource[0]);
+for (IntrospectionUtils.PropertySource source : propertySources) {
+if (source instanceof SystemPropertySource) {
+systemPropertySourceFound = true;
+}
+sourcesList.add(source);
+}
+}
+if (!systemPropertySourceFound) {
+sourcesList.add(new SystemPropertySource());
}
+source = sourcesList.toArray(new IntrospectionUtils.PropertySource[0]);
}
diff --git a/java/org/apache/tomcat/util/digester/SystemPropertySource.java
b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
new file mode 100644
index 000..49fc765
--- /dev/null
+++ b/java/org/apache/tomcat/util/digester/SystemPropertySource.java
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in
[Bug 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 Michael Osipov changed: What|Removed |Added OS||All --- Comment #1 from Michael Osipov --- How old are those systems? -- 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 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 --- Comment #2 from Miguel --- (In reply to Michael Osipov from comment #1) > How old are those systems? I haven't the data. But I see that HTTP request are 1.0 version... then is very old... We have some legacy systems. One of these is a SMS Center that we can't change. We are afraid because this problem can set our max Tomcat Version to 9.0.26 (I didn't try with all versions between 9.0.26 and 9.0.41). We know that http standard specify to separate the components of a HTTP request, but this new behaviour detected in last versions generate problems for us in some use cases. -- 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 success in on tomcat-9-trunk
The Buildbot has detected a restored build on builder tomcat-9-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-9-trunk/builds/743 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' triggered this build Build Source Stamp: [branch 9.0.x] 06eb5b10d1c7852dac3d4022e45c3d28721dfd9a Blamelist: remm Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 --- Comment #3 from Mark Thomas --- This stricter parsing was introduced as part of the fix for CVE-2020-1935. Because the fix was in response to a security issue, that makes it a lot less likely the current behaviour will be changed. I'll note that both RFC 7230 and RFC 2616 state that recipients MAY treat single LR as a line terminator. That makes the behaviour entirely optional and Tomcat is still fully HTTP spec compliant by opting to reject requests that use LF as the line terminator. I need to look into the details of that vulnerability to see if there are any options to relax the current behaviour without re-introducing a security concern. -- 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 65273] New: NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 Bug ID: 65273 Summary: NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.57 in Jira Product: Tomcat 8 Version: 8.5.57 Hardware: PC Status: NEW Severity: major Priority: P2 Component: Packaging Assignee: dev@tomcat.apache.org Reporter: angelica.sala...@easesolutions.com Target Milestone: Hello, I am unsure if this is the correct channel to make this report. Let me know either way. I am from Easesolutions, vendor of R4J - Requirements Management for Jira. In our application, we are using the Apache POI library to support our Word Export capabilities. Recently, we have been receiving reports from customers with the same error: java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller at org.apache.poi.openxml4j.opc.OPCPackage.init(OPCPackage.java:161) [?:?] at org.apache.poi.openxml4j.opc.OPCPackage.(OPCPackage.java:141) [?:?] at org.apache.poi.openxml4j.opc.ZipPackage.(ZipPackage.java:97) [?:?] at org.apache.poi.openxml4j.opc.OPCPackage.open(OPCPackage.java:324) [?:?] This looks like a dependency/classpath issue. The thing is, we have not changed our POI dependencies since 2017 and have released several versions with no change and now it's suddenly acting up. And after trying many things, we are now very lost. Ref to our developer community post: https://community.developer.atlassian.com/t/class-cannot-be-loaded-when-restarting-jira-software/47421/3 This is being experienced intermittently by customers. For example, some have our application with the same version installed in multiple nodes but only experience the issue in 1 node. We have not been able to reproduce the issue in our own environments. It seems that the common action for all these customers before experiencing the issue was that they upgraded Jira to a version that had Apache version 8.57 and up. Ref: https://confluence.atlassian.com/jiracore/bundled-tomcat-and-java-versions-1013854250.html Hope you can help point us in the right direction. Thank you and best regards, Angelica -- 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 65273] NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 Angelica Salazar changed: What|Removed |Added OS||All --- Comment #1 from Angelica Salazar --- Correction: Apache version 8.5.57 and up -- 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 65273] NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.5.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 Mark Thomas changed: What|Removed |Added Summary|NoClassDefFoundError in |NoClassDefFoundError in |Apache POI dependency after |Apache POI dependency after |upgrading to Tomcat 8.57 in |upgrading to Tomcat 8.5.57 |Jira|in Jira -- 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 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 --- Comment #4 from Miguel --- (In reply to Mark Thomas from comment #3) > This stricter parsing was introduced as part of the fix for CVE-2020-1935. > > Because the fix was in response to a security issue, that makes it a lot > less likely the current behaviour will be changed. > > I'll note that both RFC 7230 and RFC 2616 state that recipients MAY treat > single LR as a line terminator. That makes the behaviour entirely optional > and Tomcat is still fully HTTP spec compliant by opting to reject requests > that use LF as the line terminator. > > I need to look into the details of that vulnerability to see if there are > any options to relax the current behaviour without re-introducing a security > concern. Thank you for your work. Additional information: Now we see that the first version with problems are 9.0.31 (doesn't response) and with 9.0.33 the response is the reported originally. We wait for news. Regards -- 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 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 --- Comment #5 from Mark Thomas --- I've started to look at this. So far I have spotted a couple of minor issues with the current parsing that I need to fix. Commits for those will follow shortly. I haven't yet found any reason not to allow LF as a line terminator but I am still reviewing the parsing code. -- 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 (c07530f -> 2ce4ea2)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git. from c07530f Refactor system property source to be more flexible new e5468e2 Reject invalid HTTP protocols with 400 rather than 505 new 2ce4ea2 Fix off by one issue in error message generation The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/org/apache/coyote/http11/Http11InputBuffer.java | 4 ++-- .../apache/coyote/http11/TestHttp11InputBufferCRLF.java| 7 +++ webapps/docs/changelog.xml | 14 ++ 3 files changed, 23 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/02: Reject invalid HTTP protocols with 400 rather than 505
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit e5468e2a8d3a90b3fb831bd83b156b32736f
Author: Mark Thomas
AuthorDate: Wed Apr 28 17:21:13 2021 +0100
Reject invalid HTTP protocols with 400 rather than 505
---
java/org/apache/coyote/http11/Http11InputBuffer.java | 2 +-
test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java | 7 +++
webapps/docs/changelog.xml | 9 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index e3ace89..e6255dd 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -554,7 +554,7 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
} else if (prevChr == Constants.CR && chr == Constants.LF) {
end = pos - 1;
parsingRequestLineEol = true;
-} else if (!HttpParser.isHttpProtocol(chr)) {
+} else if (prevChr == Constants.CR ||
!HttpParser.isHttpProtocol(chr)) {
String invalidProtocol =
parseInvalid(parsingRequestLineStart, byteBuffer);
throw new
IllegalArgumentException(sm.getString("iib.invalidHttpProtocol",
invalidProtocol));
}
diff --git a/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
b/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
index 829912b..a953031 100644
--- a/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
+++ b/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
@@ -74,6 +74,13 @@ public class TestHttp11InputBufferCRLF extends
TomcatBaseTest {
CRLF,
Boolean.FALSE, parameterSets);
+// Standard HTTP/1.1 request with invalid HTTP protocol
+addRequestWithSplits("GET /test HTTP/" + CR + "1.1" + CRLF +
+"Host: localhost:8080" + CRLF +
+"Connection: close" + CRLF +
+CRLF,
+Boolean.FALSE, Boolean.FALSE, parameterSets);
+
// Invalid HTTP/1.1 request
addRequestWithSplits("GET /te
+
+
+
+Ensure that all HTTP requests that contain an invalid character in the
+protocol component of the request line are rejected with a 400 response
+rather than some requests being rejected with a 505 response. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/02: Fix off by one issue in error message generation
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 2ce4ea2f8e9111269e990fff640b48847b9e6d87
Author: Mark Thomas
AuthorDate: Wed Apr 28 17:22:24 2021 +0100
Fix off by one issue in error message generation
---
java/org/apache/coyote/http11/Http11InputBuffer.java | 2 +-
webapps/docs/changelog.xml | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index e6255dd..81a3a5a 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -624,7 +624,7 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
while (buffer.hasRemaining() && b != 0x20) {
b = buffer.get();
}
-String result = HeaderUtil.toPrintableString(buffer.array(),
buffer.arrayOffset() + startPos, buffer.position() - startPos - 1);
+String result = HeaderUtil.toPrintableString(buffer.array(),
buffer.arrayOffset() + startPos, buffer.position() - startPos);
if (b != 0x20) {
// Ran out of buffer rather than found a space
result = result + "...";
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index bc51e67..ce24492 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -138,6 +138,11 @@
protocol component of the request line are rejected with a 400 response
rather than some requests being rejected with a 505 response. (markt)
+
+When generating the error message for an HTTP request with an invalid
+request line, ensure that all the available data is included in the
+error message. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated (06eb5b1 -> 7b64161)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. from 06eb5b1 Refactor system property source to be more flexible add 8be9764 Reject invalid HTTP protocols with 400 rather than 505 add 7b64161 Fix off by one issue in error message generation No new revisions were added by this update. Summary of changes: java/org/apache/coyote/http11/Http11InputBuffer.java | 4 ++-- .../apache/coyote/http11/TestHttp11InputBufferCRLF.java| 7 +++ webapps/docs/changelog.xml | 14 ++ 3 files changed, 23 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/02: Reject invalid HTTP protocols with 400 rather than 505
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 559a05015601f44de09052cc3ca99f1aa1b4df15
Author: Mark Thomas
AuthorDate: Wed Apr 28 17:21:13 2021 +0100
Reject invalid HTTP protocols with 400 rather than 505
---
java/org/apache/coyote/http11/Http11InputBuffer.java | 2 +-
test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java | 7 +++
webapps/docs/changelog.xml | 9 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index d32d6ff..4b7f82d 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -568,7 +568,7 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
} else if (prevChr == Constants.CR && chr == Constants.LF) {
end = pos - 1;
parsingRequestLineEol = true;
-} else if (!HttpParser.isHttpProtocol(chr)) {
+} else if (prevChr == Constants.CR ||
!HttpParser.isHttpProtocol(chr)) {
String invalidProtocol =
parseInvalid(parsingRequestLineStart, byteBuffer);
throw new
IllegalArgumentException(sm.getString("iib.invalidHttpProtocol",
invalidProtocol));
}
diff --git a/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
b/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
index 829912b..a953031 100644
--- a/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
+++ b/test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java
@@ -74,6 +74,13 @@ public class TestHttp11InputBufferCRLF extends
TomcatBaseTest {
CRLF,
Boolean.FALSE, parameterSets);
+// Standard HTTP/1.1 request with invalid HTTP protocol
+addRequestWithSplits("GET /test HTTP/" + CR + "1.1" + CRLF +
+"Host: localhost:8080" + CRLF +
+"Connection: close" + CRLF +
+CRLF,
+Boolean.FALSE, Boolean.FALSE, parameterSets);
+
// Invalid HTTP/1.1 request
addRequestWithSplits("GET /te
+
+
+
+Ensure that all HTTP requests that contain an invalid character in the
+protocol component of the request line are rejected with a 400 response
+rather than some requests being rejected with a 505 response. (markt)
+
+
+
-
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 (2f9a206 -> a2e465c)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. from 2f9a206 Refactor system property source to be more flexible new 559a050 Reject invalid HTTP protocols with 400 rather than 505 new a2e465c Fix off by one issue in error message generation The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: java/org/apache/coyote/http11/Http11InputBuffer.java | 4 ++-- .../apache/coyote/http11/TestHttp11InputBufferCRLF.java| 7 +++ webapps/docs/changelog.xml | 14 ++ 3 files changed, 23 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/02: Fix off by one issue in error message generation
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit a2e465cfd980b8350656205f1c6515388f5a1612
Author: Mark Thomas
AuthorDate: Wed Apr 28 17:22:24 2021 +0100
Fix off by one issue in error message generation
---
java/org/apache/coyote/http11/Http11InputBuffer.java | 2 +-
webapps/docs/changelog.xml | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 4b7f82d..b8fcee3 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -638,7 +638,7 @@ public class Http11InputBuffer implements InputBuffer,
ApplicationBufferHandler
while (buffer.hasRemaining() && b != 0x20) {
b = buffer.get();
}
-String result = HeaderUtil.toPrintableString(buffer.array(),
buffer.arrayOffset() + startPos, buffer.position() - startPos - 1);
+String result = HeaderUtil.toPrintableString(buffer.array(),
buffer.arrayOffset() + startPos, buffer.position() - startPos);
if (b != 0x20) {
// Ran out of buffer rather than found a space
result = result + "...";
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a535443..6657c4b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -134,6 +134,11 @@
protocol component of the request line are rejected with a 400 response
rather than some requests being rejected with a 505 response. (markt)
+
+When generating the error message for an HTTP request with an invalid
+request line, ensure that all the available data is included in the
+error message. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf opened a new pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
markt-asf opened a new pull request #417: URL: https://github.com/apache/tomcat/pull/417 Potential fix for https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 Needs careful review, hence using a PR. If you spot any potential ways an invalid HTTP request line or header could be: - accepted as valid - rejected later than necessary - rejected for the 'wrong' reason or any other potential parsing error please report it. For bonus points provide a test case that demonstrates the issue. As always, anything that might have security implications for a current Tomcat release should go to security@a.o rather than here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65272] Problems proccessing HTTP request without CR in last versions
https://bz.apache.org/bugzilla/show_bug.cgi?id=65272 --- Comment #6 from Mark Thomas --- It currently looks like this is fixable. PR at https://github.com/apache/tomcat/pull/417 Need to allow time for the Tomcat community to review the PR. -- 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 65273] NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.5.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 --- Comment #2 from Mark Thomas --- First the good news. I can recreate this. I downloaded trail versions of Jira and R4J, created a single issue, requested an export and saw the exception and at the bottom of the stack trace: "Caused by: java.lang.ClassCastException: org.apache.xerces.stax.XMLEventFactoryImpl cannot be cast to javax.xml.stream.XMLEventFactory" The bad news is the Jira has its own class loader structure for plug-ins. I suspect a change in this area may be a factor. That isn't something the Tomcat team is going to be able to help with. I'm technically a committer for POI (I helped out with the ALv1 to ALv2 license migration many, many years ago) but I do not know POI at all. I'll have a look to see if I can create a simpler test case and/or find any clues to what might be going on but the most likely result is that this issue will be closed as INVALID as there isn't any evidence that points to a Tomcat issue at the root if 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
[GitHub] [tomcat] ChristopherSchultz commented on a change in pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
ChristopherSchultz commented on a change in pull request #417:
URL: https://github.com/apache/tomcat/pull/417#discussion_r622458605
##
File path: webapps/docs/changelog.xml
##
@@ -143,6 +143,12 @@
request line, ensure that all the available data is included in the
error message. (markt)
+
+65272: Restore the optional HTTP feature that allows
+LF to be treated as a line terminator as well as the
Review comment:
This is specifically for a line-terminator for request-line and headers,
correct? Is it worth mentioning that specifically?
##
File path: java/org/apache/coyote/http11/Http11InputBuffer.java
##
@@ -550,10 +550,15 @@ boolean parseRequestLine(boolean keptAlive, int
connectionTimeout, int keepAlive
prevChr = chr;
chr = byteBuffer.get();
if (chr == Constants.CR) {
-// Possible end of request line. Need LF next.
+// Possible end of request line. Need LF next else invalid.
} else if (prevChr == Constants.CR && chr == Constants.LF) {
+// CRLF is the standard line terminator
end = pos - 1;
parsingRequestLineEol = true;
+} else if (chr == Constants.LF) {
Review comment:
Is it worth "fingerprinting" a message to determine if it is
self-consistent? That is, a message is allowable with LF-terminated
request/headers but _only_ if *all* of its headers and the request line are
terminated with LF (only)? Or is that being unnecessarily picky and
complicating the code?
##
File path: test/org/apache/coyote/http11/TestHttp11InputBuffer.java
##
@@ -687,24 +691,6 @@ public void testInvalidEndOfRequestLine01() {
}
-@Test
Review comment:
I would leave this test in, but change its nature (i.e. require that the
response code is 200). Or is your assertion that the "correct" test is below in
`test/org/apache/coyote/http11/TestHttp11InputBufferCRLF.java `?
##
File path: java/org/apache/coyote/http11/Http11InputBuffer.java
##
@@ -841,7 +846,8 @@ private HeaderParseStatus parseHeader() throws IOException {
if (chr == Constants.CR && prevChr != Constants.CR) {
Review comment:
This appears to essentially ignore (all?) CR characters in headers. I'm
not sure that's what we want.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65273] NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.5.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 --- Comment #3 from Angelica Salazar --- (In reply to Mark Thomas from comment #2) > First the good news. I can recreate this. I downloaded trail versions of > Jira and R4J, created a single issue, requested an export and saw the > exception and at the bottom of the stack trace: > > "Caused by: java.lang.ClassCastException: > org.apache.xerces.stax.XMLEventFactoryImpl cannot be cast to > javax.xml.stream.XMLEventFactory" > > The bad news is the Jira has its own class loader structure for plug-ins. I > suspect a change in this area may be a factor. That isn't something the > Tomcat team is going to be able to help with. > > I'm technically a committer for POI (I helped out with the ALv1 to ALv2 > license migration many, many years ago) but I do not know POI at all. I'll > have a look to see if I can create a simpler test case and/or find any clues > to what might be going on but the most likely result is that this issue will > be closed as INVALID as there isn't any evidence that points to a Tomcat > issue at the root if it. Hello Mark, May I ask for the steps you did to produce the error: "Caused by: java.lang.ClassCastException: org.apache.xerces.stax.XMLEventFactoryImpl cannot be cast to javax.xml.stream.XMLEventFactory"? An idea on the type of environment you installed it in will also be helpful as we're struggling to reproduce the issue on our own environments. After this, if it's not related to Apache Tomcat, please close the issue. I truly appreciate the response. Thank you and best regards, Angelica -- 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
