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/1639 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] 81e48b3ffea2afff024aa6b28c841c16decd34be 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
svn commit: r38506 - /dev/tomcat/tomcat-7/v7.0.102/
Author: violetagg Date: Fri Mar 13 20:03:16 2020 New Revision: 38506 Log: Tomcat 7.0.102 vote did not pass Removed: dev/tomcat/tomcat-7/v7.0.102/ - 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: Tomcat 7.0.102 vote did not pass
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 81e48b3 Tomcat 7.0.102 vote did not pass 81e48b3 is described below commit 81e48b3ffea2afff024aa6b28c841c16decd34be Author: Violeta Georgieva AuthorDate: Fri Mar 13 21:59:38 2020 +0200 Tomcat 7.0.102 vote did not pass --- 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 a36b252..df46472 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -71,7 +71,7 @@ - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Nexus: Staging Repository Dropped
Message from: https://repository.apache.orgDescription:Tomcat 7.0.102 vote did not passDeployer 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 orgapachetomcat-1259 staging repository has been dropped.Action performed by Violeta Georgieva Georgieva (violetagg)
Re: [VOTE] Release Apache Tomcat 7.0.102
На пт, 13.03.2020 г. в 18:10 Mark Thomas написа: > > On 12/03/2020 12:39, Violeta Georgieva wrote: > > > > > The proposed 7.0.102 release is: > > [X] Broken - do not release > > [ ] Stable - go ahead and release as 7.0.102 Stable > > Sorry. > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 > > Fixed in 7.0.x Thanks I'll prepare Tomcat 7.0.103 tomorrow morning. Regards, Violeta
[Bug 64226] Tomcat 9 can return HTTP date headers in timzone other than GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=64226 --- Comment #2 from Christopher Schultz --- Yet another wonderful feature of SimpleDateFormat. I had no idea that parsing a date string could poison the time zone of a SimpleDateFormat object. -- 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: [tomcat] branch master updated: Add a check that the URIEncoding is a superset of US-ASCII.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/13/20 07:48, Mark Thomas wrote: > On 13/03/2020 11:37, ma...@apache.org wrote: >> 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 >> >> >> The following commit(s) were added to refs/heads/master by this >> push: new 07aabd5 Add a check that the URIEncoding is a superset >> of US-ASCII. 07aabd5 is described below >> >> commit 07aabd553de3af3744b16014765e32d2d276a140 Author: Mark >> Thomas AuthorDate: Fri Mar 13 11:36:54 2020 >> + >> >> Add a check that the URIEncoding is a superset of US-ASCII. >> >> This is a requirement of RFC7230, section 3. > > This really needs to be back-ported. Some improvements in handing > of edge cases in URIs depends on it. > > The question is how strict do we want to be with older versions? > Options are: a) ignore, log a warning and use the default (what > Tomcat 10 now does) b) same as a) by default but with an option to > switch to c) c) log a warning but use the requested encoding > > Past experience suggests there will be users, somewhere, using > inappropriate encodings. And their sites won't work with any web browser that hasn't been seriously lobotomized. > RFC 7230 references potential security vulnerabilities of > inappropriate encodings (I'd expect request smuggling and/or header > injection). > > I'm thinking c) log a warning for a couple of releases then switch > to a). Possibly switching 8.5.x a couple of releases after we > switch 9.0.x and 7.0.x a couple of releases after 8.5.x (if at all > given the EOL announcement). I'd prefer to avoid b) and yet another > configuration option. I'm okay with (c) but I'd be just as fine with (a). No reason consider (b) IMO. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5r3nUACgkQHPApP6U8 pFicPxAAhfHx2C48IWwDeFDeoQa710hFfTC4H3NSU8VX01l3bVNsa/4yYpMjc59F 6LJxz5tzZaecnxhEH0TWbl/PQ9nYiXSmTCD4qVz08nwYbCp5mJpUyW79OyWG0jyT 6WtDSXblfKJVMdIkStn3HcM05bXlGvUc5mxMpNVPiBIZiwjcPgr22D15PyiVn0O5 NRPCWGnxj2SOeQHmDJuNDoXsWgyGHEKmgJAn+9Bv8F1s5ibAqh0ne5BlD16De2jT xbMb9CCuysk3Tk1bLfyTVbKKgxD3XDtnU4wxB/r482TkChH1yTX8lVME9fQfuXC+ 1Q/XZyMAGbtW5ayuNyGX0v01w3mxba3gG0DbAFfHewHJzM6fYMYoPBZXSHFAMaO5 vMYXAsFGC+s3R1xXP1LThrgoWl0wvW4cuhMUee1GGGpRZ15IoWMw4b4E7N2V0V4x KxxFm/8i3+A7FDm1zyWNnSMcCC51jujrARNG+XFFFk+E7FRUIAhn2vm4GkU3pcxu 1Ib0xMzIQiZJ1wwLWki5p7/bPL5YbJtN78RUVlw5PO/6bjR8YbmZ62dWkAziJZk4 IJCmLsEFWM9LuBFHc2ihs8PzlWOniJMLP58FTJ3sJSk4V3mIDjmvEUIkBMEsGYEI X5Inu9ibtoFrcaO0t4aX4V9ce2I+vTQchYdLHcPXb+xan/2I5zE= =kj4d -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #6 from Michael Osipov --- (In reply to Mark Thomas from comment #5) > See https://github.com/eclipse-ee4j/servlet-api/issues/307 for a description > of what other containers do. > > Options appear to be: > a) container sends it after auth (current Tomcat behaviour) > b) container sends it when an InputStream / Reader is obtained > c) container sends it when an InputStream / Reader is first used > > I'm currently leaning towards adding an option to select between a) and b) > but as an Enum so additional options could be added later. Not only auth, on any status != 2xx. You may remember my redirect example on the mailing list. At no point a filter should need to obtain/peek/consume the input stream if a decision has to done based on headers 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
[Bug 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 --- Comment #17 from Roland --- Okay, then sorry again. I saw that the "/" removal for jarPath happened in WebappClassLoaderBase and I was afraid that it needs to be done for the call in line 1594 too for satisfying other callers than WebappServiceLoader. -- 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: [CANCEL][VOTE] Release Apache Tomcat 7.0.102
На чт, 12.03.2020 г. в 14:39 Violeta Georgieva написа: > > The proposed Apache Tomcat 7.0.102 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.102/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1259/ > The git tag is: > https://github.com/apache/tomcat/tree/7.0.102 > 672980cee0803516f0a7c4dd750e61e914089ea7 > > The proposed 7.0.102 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 7.0.102 Stable I'm canceling the vote because of https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Regards, Violeta >
[Bug 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #16 from Mark Thomas --- No, the web application class loader isn't loading the SCI. It is delegating that to its parent. The fix (in WebappServiceLoader) is the correct one. -- 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 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 --- Comment #15 from Roland --- Sorry for the confusion. I found this by "visual inspection". You wrote "the class loader being used hasn't got the same work-around that Tomcat's class loader has". Is WebappClassLoaderBase the Tomcat class loader? Because WebappClassLoaderBase is used in my case. And WebappClassLoaderBase line 1594 makes the difference for me. I am just unsure if the "/" has to be fixed in the caller or in WebappClassLoaderBase itself. -- 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 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 --- Comment #14 from Mark Thomas --- I'm confused. How did removing the leading "/" manage to fix it for you as per comment #10 if, with that fix applied, it is still broken? -- 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 57661] Delay sending of 100 continue response until application tries to read request body
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661 --- Comment #5 from Mark Thomas --- See https://github.com/eclipse-ee4j/servlet-api/issues/307 for a description of what other containers do. Options appear to be: a) container sends it after auth (current Tomcat behaviour) b) container sends it when an InputStream / Reader is obtained c) container sends it when an InputStream / Reader is first used I'm currently leaning towards adding an option to select between a) and b) but as an Enum so additional options could be added later. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-7-trunk/builds/1638 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] 66d6ccfe1a0cde856a9fed6d17e03c8707ce1eb3 Blamelist: Mark Thomas BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Roland changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #13 from Roland --- Thanks for the quick fix, but I investigated a bit more. There is still something wrong. The application *IS* using WebappClassLoaderBase from Tomcat. I see that there is code to remove the leading slash in line 1574, which is executed. The bug is in line 1594. The call to "super.findResources" still uses the "name" variable, but it should use the "jarPath" variable. -- 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.102
On 12/03/2020 12:39, Violeta Georgieva wrote: > The proposed 7.0.102 release is: > [X] Broken - do not release > [ ] Stable - go ahead and release as 7.0.102 Stable Sorry. https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Fixed in 7.0.x Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Mark Thomas --- Thanks for the report. Fixed in 7.0.x for 7.0.103 onwards. -- 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 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 Roland changed: What|Removed |Added CC||rmuelle...@posteo.de -- 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 7.0.x updated: Additional fix for BZ 64191
This is an automated email from the ASF dual-hosted git repository.
markt 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 66d6ccf Additional fix for BZ 64191
66d6ccf is described below
commit 66d6ccfe1a0cde856a9fed6d17e03c8707ce1eb3
Author: Mark Thomas
AuthorDate: Fri Mar 13 16:09:28 2020 +
Additional fix for BZ 64191
When embedding a class loader may be used that does not have the
work-around that Tomcat web application class loader has.
---
java/org/apache/catalina/startup/WebappServiceLoader.java | 2 +-
webapps/docs/changelog.xml| 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/WebappServiceLoader.java
b/java/org/apache/catalina/startup/WebappServiceLoader.java
index f22e7a8..efdf002 100644
--- a/java/org/apache/catalina/startup/WebappServiceLoader.java
+++ b/java/org/apache/catalina/startup/WebappServiceLoader.java
@@ -108,7 +108,7 @@ public class WebappServiceLoader {
if (orderedLibs == null) {
// No ordered libs, so use every service definition we can find
if (loader instanceof URLClassLoader) {
-Enumeration resources = ((URLClassLoader)
loader).findResources("/" + configFile);
+Enumeration resources = ((URLClassLoader)
loader).findResources(configFile);
while (resources.hasMoreElements()) {
URL resource = resources.nextElement();
parseConfigFile(applicationServicesFound, resource);
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a0d9bdc..a36b252 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -60,6 +60,16 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+64191: Make an additional fix for the SCI regression
+introduced by the fix for 64021 for the case, such as when
+embedding, when the class loader performing the SCI service lookup is
not
+the Tomcat web application class loader. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 --- Comment #11 from Mark Thomas --- I suspect that is because the class loader being used hasn't got the same work-around that Tomcat's class loader has. I want to run a few tests first but I think the answer is going to be removing the leading slash in that call. -- 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 64191] Applications not working with 7.0.100
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 rmuelle...@posteo.de changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #10 from rmuelle...@posteo.de --- I have the same issue as described in Bug 64220 using Tomcat 7.0.102 from https://repository.apache.org/content/repositories/orgapachetomcat-1259/ with the tomcat7-maven-plugin. In WebappServiceLoader line 111 the call to findResources does not return any results. The value of the configFile variable is "META-INF/services/javax.servlet.ServletContainerInitializer". If I re-execute the findResources call in the debugger with removing the preceding "/" in line 111, I get a result: resources = ((URLClassLoader) loader).findResources(configFile) Then my Spring Boot application starts again. -- 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: Proposed changes to UDecoder.ALLOW_ENCODED_SLASH
Am 2020-03-13 um 15:35 schrieb Mark Thomas:
Hi all,
I am writing this up as this is a change I'd like to make in Tomcat 10
that I think is important to get right. It may also get back-ported.
This first arose in this mod_jk bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Ignoring the mod_jk aspects for now (they will come later) the bug
report raises the important question of how to handle the case where the
ID for a resource in a RESTful API includes a "/".
At the moment, Tomcat does not handle this correctly. If
ALLOW_ENCODED_SLASH is false, the request is rejected. If it is true,
the wrong resource identifier will be used. This is an edge case, but
one I'd like to fix.
My research led me back to RFC 3986. Quoting from section 2.2:
The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-
encoding a reserved character, or decoding a percent-encoded octet
that corresponds to a reserved character, will change how the URI is
interpreted by most applications. Thus, characters in the reserved
set are protected from normalization and are therefore safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI.
My reading of this is that there are some %nn sequences that we should
*never* decode. The values we pass to applications for ServletPath,
PathInfo etc. should still include these %nn sequences and the
application should decode them.
My next thought was "Which %nn sequences should be leave alone?". That
got me thinking about URIEncoding values and how to differentiate
between a %nn sequence we wanted to leave alone and the same sequence
appearing where a code point is represented by multiple bytes.
Fortunately, RFC7230 saves us from that complication as it requires all
encodings to be supersets of US-ASCII. Or to put is another way, the
only time %nn appears where nn is in the range 00 to 7F that %nn
sequence will *always* be representing the equivalent US-ASCII code point.
So, that simplifies things a little as we go back to considering which
%nn sequences we have to leave alone.
The starting point is "reserved" characters. From RFC 3986:
reserved= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
We are talking about URIs in Tomcat which, at the point we %nn decode,
is just the path. The path parameters and query string have been removed.
From RFC 7230:
absolute-path = 1*( "/" segment )
and from RFC 3986:
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
So the question is, which reserved characters cannot be safely decoded
from their %nn form.
We know all subdelims because:
- they are valid characters in a segment and with the query string and
path parameters removed, none of those characters have special meaning
That leaves gen-delims
Of those ":" and "@" are explicitly allowed in a segment. So that leaves:
"/" "?" "#" "[" "]"
"?" is the query delimiter but the query string has been removed so it
is safe to %nn decode to "?".
"#" is the fragment delimiter. The fragment will never reach the server
so it is safe to %nn decode to "#".
"[" and "]" are delimiters in the host but not the path so they are safe.
That just leaves "/".
My proposal is, therefore, actually very simple:
1. Remove the UDecoder.ALLOW_ENCODED_SLASH option.
2. Replace it with a per Connector setting that has three options:
a) deny (equivalent to ALLOW_ENCODED_SLASH="false")
b) decode (equivalent to ALLOW_ENCODED_SLASH="true")
c) allow (leaves as is)
I am CC'ing our expert olegk@ on this topic because at HttpComponents we
had numerous JIRA issues regarding the handling and RFC 3986
interpretation. It is, sadly, a constant source of trouble.
Oleg, can you share your view on Mark's proposal?
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Proposed changes to UDecoder.ALLOW_ENCODED_SLASH
Hi all,
I am writing this up as this is a change I'd like to make in Tomcat 10
that I think is important to get right. It may also get back-ported.
This first arose in this mod_jk bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Ignoring the mod_jk aspects for now (they will come later) the bug
report raises the important question of how to handle the case where the
ID for a resource in a RESTful API includes a "/".
At the moment, Tomcat does not handle this correctly. If
ALLOW_ENCODED_SLASH is false, the request is rejected. If it is true,
the wrong resource identifier will be used. This is an edge case, but
one I'd like to fix.
My research led me back to RFC 3986. Quoting from section 2.2:
The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-
encoding a reserved character, or decoding a percent-encoded octet
that corresponds to a reserved character, will change how the URI is
interpreted by most applications. Thus, characters in the reserved
set are protected from normalization and are therefore safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI.
My reading of this is that there are some %nn sequences that we should
*never* decode. The values we pass to applications for ServletPath,
PathInfo etc. should still include these %nn sequences and the
application should decode them.
My next thought was "Which %nn sequences should be leave alone?". That
got me thinking about URIEncoding values and how to differentiate
between a %nn sequence we wanted to leave alone and the same sequence
appearing where a code point is represented by multiple bytes.
Fortunately, RFC7230 saves us from that complication as it requires all
encodings to be supersets of US-ASCII. Or to put is another way, the
only time %nn appears where nn is in the range 00 to 7F that %nn
sequence will *always* be representing the equivalent US-ASCII code point.
So, that simplifies things a little as we go back to considering which
%nn sequences we have to leave alone.
The starting point is "reserved" characters. From RFC 3986:
reserved= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
We are talking about URIs in Tomcat which, at the point we %nn decode,
is just the path. The path parameters and query string have been removed.
>From RFC 7230:
absolute-path = 1*( "/" segment )
and from RFC 3986:
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
So the question is, which reserved characters cannot be safely decoded
from their %nn form.
We know all subdelims because:
- they are valid characters in a segment and with the query string and
path parameters removed, none of those characters have special meaning
That leaves gen-delims
Of those ":" and "@" are explicitly allowed in a segment. So that leaves:
"/" "?" "#" "[" "]"
"?" is the query delimiter but the query string has been removed so it
is safe to %nn decode to "?".
"#" is the fragment delimiter. The fragment will never reach the server
so it is safe to %nn decode to "#".
"[" and "]" are delimiters in the host but not the path so they are safe.
That just leaves "/".
My proposal is, therefore, actually very simple:
1. Remove the UDecoder.ALLOW_ENCODED_SLASH option.
2. Replace it with a per Connector setting that has three options:
a) deny (equivalent to ALLOW_ENCODED_SLASH="false")
b) decode (equivalent to ALLOW_ENCODED_SLASH="true")
c) allow (leaves as is)
Thoughts?
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] martin-g commented on issue #262: Fix and tests for tomcat bug #64226
martin-g commented on issue #262: Fix and tests for tomcat bug #64226 URL: https://github.com/apache/tomcat/pull/262#issuecomment-598706509 IMO for the branches where Java 8 is minimum we should switch to Java 8 DateTime APIs. java.time.format.DateTimeFormatter is thread-safe. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/5027 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 07aabd553de3af3744b16014765e32d2d276a140 Blamelist: Mark Thomas 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 64226] Tomcat 9 can return HTTP date headers in timzone other than GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=64226 Gary Thomas changed: What|Removed |Added OS||All --- Comment #1 from Gary Thomas --- Added pull request https://github.com/apache/tomcat/pull/262 containing test and fix for this issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] gazzyt opened a new pull request #262: Fix and tests for tomcat bug #64226
gazzyt opened a new pull request #262: Fix and tests for tomcat bug #64226 URL: https://github.com/apache/tomcat/pull/262 https://bz.apache.org/bugzilla/show_bug.cgi?id=64226 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] gazzyt closed pull request #261: Fix and unit test for bug 64226
gazzyt closed pull request #261: Fix and unit test for bug 64226 URL: https://github.com/apache/tomcat/pull/261 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 With regards, Apache Git Services - 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: Deprecate code that is removed in Tomcat 10
This is an automated email from the ASF dual-hosted git repository.
markt 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 7d9d931 Deprecate code that is removed in Tomcat 10
7d9d931 is described below
commit 7d9d931aae3266b634b7731731a342ff469c6980
Author: Mark Thomas
AuthorDate: Fri Mar 13 11:59:38 2020 +
Deprecate code that is removed in Tomcat 10
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 6 ++
1 file changed, 6 insertions(+)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 5955731..16d157f 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -641,6 +641,9 @@ public class CoyoteAdapter implements Adapter {
// Character decoding
convertURI(decodedURI, request);
// Check that the URI is still normalized
+// Note: checkNormalize is deprecated because the test is no
+// longer required in Tomcat 10 onwards and has been
+// removed
if (!checkNormalize(req.decodedURI())) {
response.sendError(400, "Invalid URI");
}
@@ -1247,7 +1250,10 @@ public class CoyoteAdapter implements Adapter {
* @return false if sequences that are supposed to be
* normalized are still present in the URI, otherwise
* true
+ *
+ * @deprecated This code will be removed in Apache Tomcat 10 onwards
*/
+@Deprecated
public static boolean checkNormalize(MessageBytes uriMB) {
CharChunk uriCC = uriMB.getCharChunk();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated (07aabd5 -> cf7196b)
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 07aabd5 Add a check that the URIEncoding is a superset of US-ASCII. new 571d076 Remove the checkNormalize test that is no longer necessary new 9b70c91 Deprecate unused code new cf7196b Remove deprecated code The 3 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: .../apache/catalina/connector/CoyoteAdapter.java | 72 +- 1 file changed, 3 insertions(+), 69 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 03/03: Remove deprecated code
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 cf7196b09d687c4ceb1c52830b405e1c60197181
Author: Mark Thomas
AuthorDate: Fri Mar 13 12:01:17 2020 +
Remove deprecated code
---
.../apache/catalina/connector/CoyoteAdapter.java | 68 --
1 file changed, 68 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 2862eb2..1d21a24 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -1238,74 +1238,6 @@ public class CoyoteAdapter implements Adapter {
/**
- * Check that the URI is normalized following character decoding. This
- * method checks for "\", 0, "//", "/./" and "/../".
- *
- * @param uriMB URI to be checked (should be chars)
- *
- * @return false if sequences that are supposed to be
- * normalized are still present in the URI, otherwise
- * true
- *
- * @deprecated This code will be removed in Apache Tomcat 10 onwards
- */
-@Deprecated
-public static boolean checkNormalize(MessageBytes uriMB) {
-
-CharChunk uriCC = uriMB.getCharChunk();
-char[] c = uriCC.getChars();
-int start = uriCC.getStart();
-int end = uriCC.getEnd();
-
-int pos = 0;
-
-// Check for '\' and 0
-for (pos = start; pos < end; pos++) {
-if (c[pos] == '\\') {
-return false;
-}
-if (c[pos] == 0) {
-return false;
-}
-}
-
-// Check for "//"
-for (pos = start; pos < (end - 1); pos++) {
-if (c[pos] == '/') {
-if (c[pos + 1] == '/') {
-return false;
-}
-}
-}
-
-// Check for ending with "/." or "/.."
-if (((end - start) >= 2) && (c[end - 1] == '.')) {
-if ((c[end - 2] == '/')
-|| ((c[end - 2] == '.')
-&& (c[end - 3] == '/'))) {
-return false;
-}
-}
-
-// Check for "/./"
-if (uriCC.indexOf("/./", 0, 3, 0) >= 0) {
-return false;
-}
-
-// Check for "/../"
-if (uriCC.indexOf("/../", 0, 4, 0) >= 0) {
-return false;
-}
-
-return true;
-
-}
-
-
-// -- Protected Methods
-
-
-/**
* Copy an array of bytes to a different position. Used during
* normalization.
*
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/03: Deprecate unused code
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 9b70c91abef924cc68b1a7f6bc4f1e9911e3e13a
Author: Mark Thomas
AuthorDate: Fri Mar 13 11:59:38 2020 +
Deprecate unused code
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 3 +++
1 file changed, 3 insertions(+)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index 66cd016..2862eb2 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -1246,7 +1246,10 @@ public class CoyoteAdapter implements Adapter {
* @return false if sequences that are supposed to be
* normalized are still present in the URI, otherwise
* true
+ *
+ * @deprecated This code will be removed in Apache Tomcat 10 onwards
*/
+@Deprecated
public static boolean checkNormalize(MessageBytes uriMB) {
CharChunk uriCC = uriMB.getCharChunk();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/03: Remove the checkNormalize test that is no longer necessary
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 571d07654ba28d1e75481b04d43d5b40b9d846bb
Author: Mark Thomas
AuthorDate: Fri Mar 13 11:58:45 2020 +
Remove the checkNormalize test that is no longer necessary
The restriction of URIEncoding to US-ASCII supersets means that it is no
longer possible for byte to character conversion to result in a URI that
is not normalized.
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index f448f8f..66cd016 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -640,10 +640,9 @@ public class CoyoteAdapter implements Adapter {
if (normalize(req.decodedURI())) {
// Character decoding
convertURI(decodedURI, request);
-// Check that the URI is still normalized
-if (!checkNormalize(req.decodedURI())) {
-response.sendError(400, "Invalid URI");
-}
+// URIEncoding values are limited to US-ASCII supersets.
+// Therefore it is not necessary to check that the URI remains
+// normalized after character decoding
} else {
response.sendError(400, "Invalid URI");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
On Fri, Mar 13, 2020 at 12:50 PM Mark Thomas wrote: > On 13/03/2020 11:36, Martin Grigorov wrote: > > > > > You neither explain a breaking use case nor modules/owb has any > > documentation :-/ > > But I will take your word and revert my change. > > > > If we should follow Romain's suggestion then probably ejb, mail, > > persistence and transaction should not be in this regexp as well. > > Make it user configurable? > +1, I suggested it already, and I think we could have package lists corresponding to spec levels. Rémy > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[GitHub] [tomcat] gazzyt opened a new pull request #261: Fix and unit test for bug 64226
gazzyt opened a new pull request #261: Fix and unit test for bug 64226 URL: https://github.com/apache/tomcat/pull/261 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64226] New: Tomcat 9 can return HTTP date headers in timzone other than GMT
https://bz.apache.org/bugzilla/show_bug.cgi?id=64226 Bug ID: 64226 Summary: Tomcat 9 can return HTTP date headers in timzone other than GMT Product: Tomcat 9 Version: 9.0.27 Hardware: PC Status: NEW Severity: regression Priority: P2 Component: Util Assignee: dev@tomcat.apache.org Reporter: gaz...@live.co.uk Target Milestone: - We have an existing web application deployed within Tomcat. Recently we upgraded Tomcat from 8.0.32 to 9.0.27. The application sets an Expires HTTP header ultimately via Response.setDateHeader. Initially the application correctly returns the Expires header in the GMT timezone but over time (since the last restart) these headers begin to be returned in CET timezone. Different nodes in the cluster will flip to CET at different times. We can flip a node to CET by sending a request with a CET date in a header e.g. $ curl -H "If-Modified-Since: Thu, 12 Mar 2020 14:40:22 CET" --verbose localhost:18000/some/url/within/our/application -o /dev/null After investigation the issue appears to be with the new ConcurrentDateFormat class which uses a ConcurrentLinkedQueue to hold a reusable collection of SimpleDateFormats. The collection is shared between the format and parse methods. When parse is called with a date string containing a timezone that is *not* GMT (e.g. "Thu, 12 Mar 2020 14:40:22 CET") then the timezone within the SimpleDateFormat used is changed to the timezone in the string (e.g. CET). This SimpleDateFormat is then placed back in the queue where it will be used by calls to format which will then return date strings in the wrong timezone. -- 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: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
On 13/03/2020 11:36, Martin Grigorov wrote: > You neither explain a breaking use case nor modules/owb has any > documentation :-/ > But I will take your word and revert my change. > > If we should follow Romain's suggestion then probably ejb, mail, > persistence and transaction should not be in this regexp as well. Make it user configurable? Mark - 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 check that the URIEncoding is a superset of US-ASCII.
On 13/03/2020 11:37, ma...@apache.org wrote: > 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 > > > The following commit(s) were added to refs/heads/master by this push: > new 07aabd5 Add a check that the URIEncoding is a superset of US-ASCII. > 07aabd5 is described below > > commit 07aabd553de3af3744b16014765e32d2d276a140 > Author: Mark Thomas > AuthorDate: Fri Mar 13 11:36:54 2020 + > > Add a check that the URIEncoding is a superset of US-ASCII. > > This is a requirement of RFC7230, section 3. This really needs to be back-ported. Some improvements in handing of edge cases in URIs depends on it. The question is how strict do we want to be with older versions? Options are: a) ignore, log a warning and use the default (what Tomcat 10 now does) b) same as a) by default but with an option to switch to c) c) log a warning but use the requested encoding Past experience suggests there will be users, somewhere, using inappropriate encodings. RFC 7230 references potential security vulnerabilities of inappropriate encodings (I'd expect request smuggling and/or header injection). I'm thinking c) log a warning for a couple of releases then switch to a). Possibly switching 8.5.x a couple of releases after we switch 9.0.x and 7.0.x a couple of releases after 8.5.x (if at all given the EOL announcement). I'd prefer to avoid b) and yet another configuration option. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Add a check that the URIEncoding is a superset of US-ASCII.
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
The following commit(s) were added to refs/heads/master by this push:
new 07aabd5 Add a check that the URIEncoding is a superset of US-ASCII.
07aabd5 is described below
commit 07aabd553de3af3744b16014765e32d2d276a140
Author: Mark Thomas
AuthorDate: Fri Mar 13 11:36:54 2020 +
Add a check that the URIEncoding is a superset of US-ASCII.
This is a requirement of RFC7230, section 3.
---
java/org/apache/catalina/connector/Connector.java | 11 ++-
.../catalina/connector/LocalStrings.properties | 1 +
java/org/apache/tomcat/util/buf/CharsetUtil.java | 58 ++
.../apache/tomcat/util/buf/TestCharsetUtil.java| 89 ++
webapps/docs/changelog.xml | 5 ++
5 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/Connector.java
b/java/org/apache/catalina/connector/Connector.java
index f37f027..43b9431 100644
--- a/java/org/apache/catalina/connector/Connector.java
+++ b/java/org/apache/catalina/connector/Connector.java
@@ -41,6 +41,7 @@ import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.buf.B2CConverter;
+import org.apache.tomcat.util.buf.CharsetUtil;
import org.apache.tomcat.util.net.SSLHostConfig;
import org.apache.tomcat.util.net.openssl.OpenSSLImplementation;
import org.apache.tomcat.util.res.StringManager;
@@ -770,10 +771,14 @@ public class Connector extends LifecycleMBeanBase {
*/
public void setURIEncoding(String URIEncoding) {
try {
-uriCharset = B2CConverter.getCharset(URIEncoding);
+ Charset charset = B2CConverter.getCharset(URIEncoding);
+ if (!CharsetUtil.isAsciiSuperset(charset)) {
+ log.error(sm.getString("coyoteConnector.notAsciiSuperset",
URIEncoding, uriCharset.name()));
+ return;
+ }
+ uriCharset = charset;
} catch (UnsupportedEncodingException e) {
-log.error(sm.getString("coyoteConnector.invalidEncoding",
-URIEncoding, uriCharset.name()), e);
+log.error(sm.getString("coyoteConnector.invalidEncoding",
URIEncoding, uriCharset.name()), e);
}
}
diff --git a/java/org/apache/catalina/connector/LocalStrings.properties
b/java/org/apache/catalina/connector/LocalStrings.properties
index 1cc68af..ef7d28f 100644
--- a/java/org/apache/catalina/connector/LocalStrings.properties
+++ b/java/org/apache/catalina/connector/LocalStrings.properties
@@ -24,6 +24,7 @@ coyoteAdapter.nullRequest=An asynchronous dispatch may only
happen on an existin
coyoteConnector.invalidEncoding=The encoding [{0}] is not recognised by the
JRE. The Connector will continue to use [{1}]
coyoteConnector.invalidPort=The connector cannot start since the specified
port value of [{0}] is invalid
+coyoteConnector.notAsciiSuperset=The encoding [{0}] is not a superset of ASCII
as required by RFC 7230. The Connector will continue to use [{1}]
coyoteConnector.parseBodyMethodNoTrace=TRACE method MUST NOT include an entity
(see RFC 2616 Section 9.6)
coyoteConnector.protocolHandlerDestroyFailed=Protocol handler destroy failed
coyoteConnector.protocolHandlerInitializationFailed=Protocol handler
initialization failed
diff --git a/java/org/apache/tomcat/util/buf/CharsetUtil.java
b/java/org/apache/tomcat/util/buf/CharsetUtil.java
new file mode 100644
index 000..fc0a09e
--- /dev/null
+++ b/java/org/apache/tomcat/util/buf/CharsetUtil.java
@@ -0,0 +1,58 @@
+/*
+ * 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
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.buf;
+
+import java.nio.BufferUnderflowException;
+import java.nio.ByteBuffer;
+import java.nio.CharBuffer;
+import java.nio.charset.CharacterCodingException;
+import java.nio.charset.Charset;
+import java.nio.charset.CharsetDecoder;
+
+public class CharsetUtil {
+
+private CharsetUtil() {
+// Utility class. Hide default constructor.
+}
[tomcat-jakartaee-migration] branch master updated: Revert "Add javax.(decorator|enterprise|inject) as ones which should be migrated"
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
The following commit(s) were added to refs/heads/master by this push:
new 4af8297 Revert "Add javax.(decorator|enterprise|inject) as ones which
should be migrated"
4af8297 is described below
commit 4af829788ff4824b962d08490235ae2886a571b4
Author: Martin Tzvetanov Grigorov
AuthorDate: Fri Mar 13 13:36:26 2020 +0200
Revert "Add javax.(decorator|enterprise|inject) as ones which should be
migrated"
This reverts commit 8dd0dde9e030e8168141184b3e51de1d674aee0b.
---
src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
b/src/main/java/org/apache/tomcat/jakartaee/Util.java
index 701134d..21e0fbf 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
@@ -23,8 +23,7 @@ import java.util.regex.Pattern;
public class Util {
private static Pattern PATTERN = Pattern.compile(
-
"javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
-+ ".]message|servlet|transaction|websocket))");
+
"javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
/**
* Get the extension of a filename
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
Hi Rémy,
On Fri, Mar 13, 2020 at 12:27 PM Rémy Maucherat wrote:
> On Fri, Mar 13, 2020 at 11:00 AM Martin Grigorov
> wrote:
>
>> Hi Rémy,
>>
>> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat wrote:
>>
>>> On Thu, Mar 12, 2020 at 3:10 PM wrote:
>>>
This is an automated email from the ASF dual-hosted git repository.
mgrigorov pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
The following commit(s) were added to refs/heads/master by this push:
new 8dd0dde Add javax.(decorator|enterprise|inject) as ones which
should be migrated
8dd0dde is described below
commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
Author: Martin Tzvetanov Grigorov
AuthorDate: Thu Mar 12 16:09:04 2020 +0200
Add javax.(decorator|enterprise|inject) as ones which should be
migrated
Those are needed for CDI applications
>>>
>>> Well, it's needed if there is a jakarta implementation of CDI [do you
>>> have one ? ...]. Right now that's not the case and it will mess things up
>>> since it's possible to use Tomcat 10 with a javax CDI and a converted
>>> webapp.
>>> See the modules/owb wrapper for example.
>>>
>>
>>> So it's a bit messy and this would need to be configurable for now.
>>>
>>
>> Here is how I understand it:
>> 1) if you deploy in EE server, like Wildfly and Glassfish, then both
>> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
>> server and they are not part of the application, so nothing will be migrated
>> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
>> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
>> are migrated and everything works
>>
>> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
>> jakarta packages are prefered than javax ones.
>>
>> Do you see a use case that is not supported at the moment ?
>>
>
> There's no point in migrating code that doesn't need to be migrated, so I
> don't understand what you are using this for. If the user is using a
> package like modules/owb, then it won't work.
>
You neither explain a breaking use case nor modules/owb has any
documentation :-/
But I will take your word and revert my change.
If we should follow Romain's suggestion then probably ejb, mail,
persistence and transaction should not be in this regexp as well.
Martin
>
> Rémy
>
>
>>
>> Martin
>>
>>
>>>
>>> Rémy
>>>
>>>
---
src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
b/src/main/java/org/apache/tomcat/jakartaee/Util.java
index 21e0fbf..701134d 100644
--- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
+++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
@@ -23,7 +23,8 @@ import java.util.regex.Pattern;
public class Util {
private static Pattern PATTERN = Pattern.compile(
-
"javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
+
"javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
++ ".]message|servlet|transaction|websocket))");
/**
* Get the extension of a filename
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64221] org.apache.tomcat.util.net.TestClientCertTls13 not skipped if TLS 1.3 is disabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=64221 --- Comment #2 from Michael Osipov --- (In reply to Mark Thomas from comment #1) > Don't do that. > > The unit tests expect TLS 1.3 to be supported when running on Java 11. Granted, but then this should be documented somewhere or the Ant build shall fail before tests start. -- 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: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
On Fri, Mar 13, 2020 at 11:00 AM Martin Grigorov
wrote:
> Hi Rémy,
>
> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat wrote:
>
>> On Thu, Mar 12, 2020 at 3:10 PM wrote:
>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> mgrigorov pushed a commit to branch master
>>> in repository
>>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>> new 8dd0dde Add javax.(decorator|enterprise|inject) as ones which
>>> should be migrated
>>> 8dd0dde is described below
>>>
>>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>>> Author: Martin Tzvetanov Grigorov
>>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>>
>>> Add javax.(decorator|enterprise|inject) as ones which should be
>>> migrated
>>>
>>> Those are needed for CDI applications
>>>
>>
>> Well, it's needed if there is a jakarta implementation of CDI [do you
>> have one ? ...]. Right now that's not the case and it will mess things up
>> since it's possible to use Tomcat 10 with a javax CDI and a converted
>> webapp.
>> See the modules/owb wrapper for example.
>>
>
>> So it's a bit messy and this would need to be configurable for now.
>>
>
> Here is how I understand it:
> 1) if you deploy in EE server, like Wildfly and Glassfish, then both
> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
> server and they are not part of the application, so nothing will be migrated
> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
> are migrated and everything works
>
> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
> jakarta packages are prefered than javax ones.
>
> Do you see a use case that is not supported at the moment ?
>
There's no point in migrating code that doesn't need to be migrated, so I
don't understand what you are using this for. If the user is using a
package like modules/owb, then it won't work.
Rémy
>
> Martin
>
>
>>
>> Rémy
>>
>>
>>> ---
>>> src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> index 21e0fbf..701134d 100644
>>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>>> public class Util {
>>>
>>> private static Pattern PATTERN = Pattern.compile(
>>> -
>>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>>> +
>>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>>> ++ ".]message|servlet|transaction|websocket))");
>>>
>>> /**
>>> * Get the extension of a filename
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
Re: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
Hi everyone,
Shouldnt tomcat tool stay aligned on tomcat stack?
Maven shade or gradle fatjar plugins solve this issue with relocation for
all users and all namespaces so not a big deal to not handle more than
tomcat IMO, otherwise all hybrid cases (between ~servlet and ee) will be
broken IMHO.
Le ven. 13 mars 2020 à 11:00, Martin Grigorov a
écrit :
> Hi Rémy,
>
> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat wrote:
>
>> On Thu, Mar 12, 2020 at 3:10 PM wrote:
>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> mgrigorov pushed a commit to branch master
>>> in repository
>>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>> new 8dd0dde Add javax.(decorator|enterprise|inject) as ones which
>>> should be migrated
>>> 8dd0dde is described below
>>>
>>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>>> Author: Martin Tzvetanov Grigorov
>>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>>
>>> Add javax.(decorator|enterprise|inject) as ones which should be
>>> migrated
>>>
>>> Those are needed for CDI applications
>>>
>>
>> Well, it's needed if there is a jakarta implementation of CDI [do you
>> have one ? ...]. Right now that's not the case and it will mess things up
>> since it's possible to use Tomcat 10 with a javax CDI and a converted
>> webapp.
>> See the modules/owb wrapper for example.
>>
>
>> So it's a bit messy and this would need to be configurable for now.
>>
>
> Here is how I understand it:
> 1) if you deploy in EE server, like Wildfly and Glassfish, then both
> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
> server and they are not part of the application, so nothing will be migrated
> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
> are migrated and everything works
>
> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
> jakarta packages are prefered than javax ones.
>
> Do you see a use case that is not supported at the moment ?
>
> Martin
>
>
>>
>> Rémy
>>
>>
>>> ---
>>> src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> index 21e0fbf..701134d 100644
>>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>>> public class Util {
>>>
>>> private static Pattern PATTERN = Pattern.compile(
>>> -
>>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>>> +
>>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>>> ++ ".]message|servlet|transaction|websocket))");
>>>
>>> /**
>>> * Get the extension of a filename
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
Re: [tomcat-jakartaee-migration] branch master updated: Add javax.(decorator|enterprise|inject) as ones which should be migrated
Hi Rémy,
On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat wrote:
> On Thu, Mar 12, 2020 at 3:10 PM wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> mgrigorov pushed a commit to branch master
>> in repository
>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>> new 8dd0dde Add javax.(decorator|enterprise|inject) as ones which
>> should be migrated
>> 8dd0dde is described below
>>
>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b
>> Author: Martin Tzvetanov Grigorov
>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200
>>
>> Add javax.(decorator|enterprise|inject) as ones which should be
>> migrated
>>
>> Those are needed for CDI applications
>>
>
> Well, it's needed if there is a jakarta implementation of CDI [do you have
> one ? ...]. Right now that's not the case and it will mess things up since
> it's possible to use Tomcat 10 with a javax CDI and a converted webapp.
> See the modules/owb wrapper for example.
>
> So it's a bit messy and this would need to be configurable for now.
>
Here is how I understand it:
1) if you deploy in EE server, like Wildfly and Glassfish, then both
cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE
server and they are not part of the application, so nothing will be migrated
2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar
and weld-servlet.jar should be in the application's WEB-INF/lib/, so both
are migrated and everything works
In both cases one is supposed to deploy in Jakarta EE 9 container, i.e.
jakarta packages are prefered than javax ones.
Do you see a use case that is not supported at the moment ?
Martin
>
> Rémy
>
>
>> ---
>> src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> index 21e0fbf..701134d 100644
>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java
>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern;
>> public class Util {
>>
>> private static Pattern PATTERN = Pattern.compile(
>> -
>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))");
>> +
>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\"
>> ++ ".]message|servlet|transaction|websocket))");
>>
>> /**
>> * Get the extension of a filename
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
[Bug 64225] An exception occurred while parse the given input as an HTTP Host header value
https://bz.apache.org/bugzilla/show_bug.cgi?id=64225 --- Comment #1 from Mark Thomas --- At the moment, reg-name is further restricted to valid DNS names. What name resolution service are you using? -- 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 64222] Getting User from SSO using SPNEGO returns Tomcat Linux user instead of Windows user above Tomcat9.0.8
https://bz.apache.org/bugzilla/show_bug.cgi?id=64222 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- That SPNEGO authentication implementation is not provided by the Apache Tomcat project. You should seek help from the provider of that library. I'll note that the Tomcat provided SPNEGO implementation is known to work with correct configuration. -- 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 64225] An exception occurred while parse the given input as an HTTP Host header value
https://bz.apache.org/bugzilla/show_bug.cgi?id=64225 zhichun xie changed: What|Removed |Added Summary|Parse the given input as an |An exception occurred while |HTTP Host header value |parse the given input as an ||HTTP Host header value -- 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 64221] org.apache.tomcat.util.net.TestClientCertTls13 not skipped if TLS 1.3 is disabled
https://bz.apache.org/bugzilla/show_bug.cgi?id=64221 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- Don't do that. The unit tests expect TLS 1.3 to be supported when running on Java 11. -- 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 64225] New: Parse the given input as an HTTP Host header value
https://bz.apache.org/bugzilla/show_bug.cgi?id=64225 Bug ID: 64225 Summary: Parse the given input as an HTTP Host header value Product: Tomcat 9 Version: unspecified Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Util Assignee: dev@tomcat.apache.org Reporter: xiezhic...@foxmail.com Target Milestone: - https://tools.ietf.org/html/rfc3986#page-18 'host:*' is http compliant, but the request will report an exception: o.apache.coyote.http11.Http11Processor : The host [*] is not valid Note: further occurrences of request parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: null at org.apache.tomcat.util.http.parser.Host.parse(Host.java:78) at org.apache.tomcat.util.http.parser.Host.parse(Host.java:45) at org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:282) at org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:809) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:384) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) The relevant source code is : https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/Host.java -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
