Re: Preparing to migrate to Tomcat 10.1 / Jakarta EE
On 05/12/2022 20:32, Christopher Schultz wrote: 4. Patch the server to provide #3 without having to include a Filter in the application deployment. 5. Extend the migration tool so you can add file extension / file type mappings in addition to the built-in ones. Or maybe even override the built-in ones. This is a lot more work than #4. I'm kind of interested in idea #4, and wanted to ask for feedback. I think #4 could be a nest solution applicable to multiple users. If placed at the end of the current getAttribute() code it would have a minimal performance impact. We should log (debug level?, separate logger like NioEndpoint.handshake?) when this happens. I can't be the only one in this situation where the Tomcat Migration Tool is great but doesn't cover some use-cases and therefore upgrades are risky and/or problematic. I'm sure. I'm expecting a bunch of issues to start showing up as folks start migrating. I think we as a community should be encouraging users to start upgrading to get over the "Jakarta Hurdle" and I think that this could be another small tool to help motivate that migration. WDYT? +1. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66175] Consider changing BasicAuthenticator to default to charset="UTF-8"
https://bz.apache.org/bugzilla/show_bug.cgi?id=66175 Michael Osipov changed: What|Removed |Added Summary|Consider changing |Consider changing |BasicAuthenticator to |BasicAuthenticator to |default to charset="UTF"|default to charset="UTF-8" -- 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 10.1.4
On 05/12/2022 17:42, Mark Thomas wrote: The proposed 10.1.4 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 10.1.4 Unit tests pass on Linux, Windows and MacOS. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.4
On Mon, Dec 5, 2022 at 6:43 PM Mark Thomas wrote: > > The proposed Apache Tomcat 10.1.4 release is now available for > voting. > > The notable changes compared to 10.1.2 are: > > - Refactor WebappLoader so it only has a runtime dependency on the >migration tool for Jakarta EE if configured to use the converter as >classes are loaded. > > - When an HTTP/2 stream was reset, the current active stream count was >not reduced. If enough resets occurred on a connection, the current >active stream count limit was reached and no new streams could be >created on that connection. > > - Update to Commons Daemon 1.3.3 > > For full details, see the change log: > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > without changes. Java EE applications designed for Tomcat 9 and earlier > may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat > will automatically convert them to Jakarta EE and copy them to the > webapps directory. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.4/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1412 > > The tag is: > https://github.com/apache/tomcat/tree/10.1.4 > a8e13f8d7e621be9f58af45f5a67e7bf847a8321 > > > The proposed 10.1.4 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 10.1.4 Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 10.1.4
> On Dec 6, 2022, at 01:42, Mark Thomas wrote: > > The proposed Apache Tomcat 10.1.4 release is now available for > voting. > > The notable changes compared to 10.1.2 are: > > - Refactor WebappLoader so it only has a runtime dependency on the > migration tool for Jakarta EE if configured to use the converter as > classes are loaded. > > - When an HTTP/2 stream was reset, the current active stream count was > not reduced. If enough resets occurred on a connection, the current > active stream count limit was reached and no new streams could be > created on that connection. > > - Update to Commons Daemon 1.3.3 > > For full details, see the change log: > https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html > > Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 > without changes. Java EE applications designed for Tomcat 9 and earlier may > be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will > automatically convert them to Jakarta EE and copy them to the webapps > directory. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.4/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1412 > > The tag is: > https://github.com/apache/tomcat/tree/10.1.4 > a8e13f8d7e621be9f58af45f5a67e7bf847a8321 > > > The proposed 10.1.4 release is: > [ ] Broken - do not release > [X ] Stable - go ahead and release as 10.1.4 Tests pass with tc-native 2.0.2 and OpenSSL 3.0.7 on macOS 12.3.1. Han > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
HTTP/2 priorities
Hi all, I plan to implement RFC 9218 [1] for HTTP/2 in Tomcat 11. Depending on how that goes, I may back-port the changes. Given the difficulties we have in prioritizing creation of responses, I plan to continue the current approach of prioritizing the sending of data when the connection window size is smaller than the currently active streams have collectively requested. My rough plan at this stage, which is likely to change as I work through the implementation, is: - remove all the code that supports the current priority tree approach - include SETTINGS_NO_RFC7540_PRIORITIES in the initial settings - implement the new priority scheme - expected to be a much simpler algorithm in Http2UpgradeHandler.allocate() Mark [1] https://www.rfc-editor.org/rfc/rfc9218.html#name-priority-parameters - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66327] Tomcat run as a windows service doesn't set the stack size accordingly
https://bz.apache.org/bugzilla/show_bug.cgi?id=66327 --- Comment #11 from Konstantin Kolinko --- FYI. Retesting with latest Java, released in late October, the results are: 1. Java version does not matter. The StackOverflowError is reproducible with OP's Sample application using Apache Tomcat 9.0.70 using 64-bit - Java 8u352 (server jvm), - Java 11.0.17 (server jvm, client jvm) from Eclipse Adoptium on Windows 10. 2. Thread matters. 2.1. Note that in the Sample application the recursive call is triggered from contextInitialized(..) method of a ServletContextListener. With the default configuration of Tomcat 9.0.70 the code runs on the "main" thread. The thread name can be seen in the localhost.2022-**-**.log file, where the StackOverflowError is logged. > 06-Dec-2022 **:**:**.*** SEVERE [main] > org.apache.catalina.core.StandardContext.listenerStart Exception sending > context initialized event to listener instance of class > [stacktest.application.ApplicationServlet] > java.lang.StackOverflowError > ... 2.2. If I change Tomcat configuration to use a separate pool of threads to start web applications, the web application starts successfully. It prints numbers up to 25000, as expected. The configuration is done by adding startStopThreads attribute to a Host, for example: For further reference, see https://tomcat.apache.org/tomcat-9.0-doc/config/host.html#Common_Attributes This is the workaround that I recommend for this issue. 2.3. Whether the stack size of the main thread can be configured, is a question for the Commons Daemon project. https://commons.apache.org/proper/commons-daemon/procrun.html There is no Apache Tomcat bug here. 3. As a side note. java.lang.Thread has a constructor that allows to specify the stackSize. > public Thread(ThreadGroup group, > Runnable target, > String name, > long stackSize) > @since 1.4 It may be that it will be useful to somebody. -- 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: Preparing to migrate to Tomcat 10.1 / Jakarta EE
Mark, On 12/6/22 03:28, Mark Thomas wrote: On 05/12/2022 20:32, Christopher Schultz wrote: 4. Patch the server to provide #3 without having to include a Filter in the application deployment. 5. Extend the migration tool so you can add file extension / file type mappings in addition to the built-in ones. Or maybe even override the built-in ones. This is a lot more work than #4. I'm kind of interested in idea #4, and wanted to ask for feedback. I think #4 could be a nest solution applicable to multiple users. If placed at the end of the current getAttribute() code it would have a minimal performance impact. We should log (debug level?, separate logger like NioEndpoint.handshake?) when this happens. I can't be the only one in this situation where the Tomcat Migration Tool is great but doesn't cover some use-cases and therefore upgrades are risky and/or problematic. I'm sure. I'm expecting a bunch of issues to start showing up as folks start migrating. I think we as a community should be encouraging users to start upgrading to get over the "Jakarta Hurdle" and I think that this could be another small tool to help motivate that migration. WDYT? +1. Cool. Based upon that feedback, I'll start working on a Filter as a PoC. It can easily be converted to a Valve or just added to Request.getAttribute. Time for a good re-reading of the servlet spec documentation ;) -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: HTTP/2 priorities
Mark, On 12/6/22 11:21, Mark Thomas wrote: Hi all, I plan to implement RFC 9218 [1] for HTTP/2 in Tomcat 11. Depending on how that goes, I may back-port the changes. Given the difficulties we have in prioritizing creation of responses, I plan to continue the current approach of prioritizing the sending of data when the connection window size is smaller than the currently active streams have collectively requested. My rough plan at this stage, which is likely to change as I work through the implementation, is: - remove all the code that supports the current priority tree approach - include SETTINGS_NO_RFC7540_PRIORITIES in the initial settings - implement the new priority scheme - expected to be a much simpler algorithm in Http2UpgradeHandler.allocate() +1 I didn't realize we had any prioritization code in Tomcat at all at this point. Why would the new implementation be simpler? Because we've been given a very straightforward set of rules by the RFC which will be replacing an ad-hoc heuristic implementation? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66327] Tomcat run as a windows service doesn't set the stack size accordingly
https://bz.apache.org/bugzilla/show_bug.cgi?id=66327 --- Comment #12 from Konstantin Preißer --- Hi, FYI, on Windows, the default thread stack size is specified in the PE header and can be set with the "editbin.exe /STACK" command [1] (and can be displayed with the "dumpbin.exe /headers" command [2]. AFAIK this size will automatically be used for the stack size of the Main thread. For the "tomcat9.exe" service wrapper from Tomcat 9.0.65 (Windows x64), it is displayed as follows (hex): 10 size of stack reserve 1000 size of stack commit i.e., a 1 MiB stack size. This seems to be the default at least when using MS Visual C++ 2022. (The .NET [Core] app host for example uses a 1.5 MiB default stack size for Windows x64.) To set it e.g. to 4 MB stack (without changing the stack commit size), you can call: editbin /STACK:4194304 tomcat9.exe [1] https://learn.microsoft.com/en-us/cpp/build/reference/stack?view=msvc-170 [2] https://learn.microsoft.com/en-us/cpp/build/reference/headers?view=msvc-170 -- 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: HTTP/2 priorities
On 06/12/2022 17:11, Christopher Schultz wrote: Mark, On 12/6/22 11:21, Mark Thomas wrote: Hi all, I plan to implement RFC 9218 [1] for HTTP/2 in Tomcat 11. Depending on how that goes, I may back-port the changes. Given the difficulties we have in prioritizing creation of responses, I plan to continue the current approach of prioritizing the sending of data when the connection window size is smaller than the currently active streams have collectively requested. My rough plan at this stage, which is likely to change as I work through the implementation, is: - remove all the code that supports the current priority tree approach - include SETTINGS_NO_RFC7540_PRIORITIES in the initial settings - implement the new priority scheme - expected to be a much simpler algorithm in Http2UpgradeHandler.allocate() +1 I didn't realize we had any prioritization code in Tomcat at all at this point. Why would the new implementation be simpler? Because we've been given a very straightforward set of rules by the RFC which will be replacing an ad-hoc heuristic implementation? The scheme described in RFC 9218 is simpler than the one described in RFC 7540. How you apply the priorities is still our problem, but the data we have to work with is a lot simpler. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Preparing to migrate to Tomcat 10.1 / Jakarta EE
пн, 5 дек. 2022 г. в 23:32, Christopher Schultz : > > All, > > I've started looking at the migration path at $work for Jakarta EE and > while Tomcat 10 has some fantastic features to help with that (hot > migration is killer IMO), there are still some potential barriers I'm > seeing to "slowly" migrating $work applications from Java EE -> Jakarta EE. > > When I say "slowly", I mean "not having to write one or more large > revision-control changes to lock-step-upgrade from e.g. Tomcat 8/9 to > Tomcat 10.1." > > One specific example is that we use Apache Velocity as our > page-generation language and AIUI, these templates will not have their > text scanned and replaced with updated strings. For example: > > #if($request.getAttribute('javax.servlet.error.request_uri')) > ... > #end > > [... skipped] > > I can think of a few ways to facilitate a dual-deployment (Tomcat 8/9 vs > 10 aka Java EE vs Jakarta EE) application, at least for the specific > example I present above: > > [... skipped] 6. I think that Migration Tool can be updated to change string constants such as the above one. There is a limited set of those names, and I expect them to always appear as a whole string among string constants. Going into java/javax/servlet of Tomcat 9 and running a search for `"javax.`, except '.LocalStrings"' l10n resources names: grep --line-number --recursive '"javax.' | grep --invert-match '.LocalStrings"' - >../found.txt I get the following 36 lines: [[[ AsyncContext.java:30:"javax.servlet.async.request_uri"; AsyncContext.java:36:"javax.servlet.async.context_path"; AsyncContext.java:42:"javax.servlet.async.mapping"; AsyncContext.java:48:"javax.servlet.async.path_info"; AsyncContext.java:54:"javax.servlet.async.servlet_path"; AsyncContext.java:60:"javax.servlet.async.query_string"; jsp/PageContext.java:139:public static final String PAGE = "javax.servlet.jsp.jspPage"; jsp/PageContext.java:145:public static final String PAGECONTEXT = "javax.servlet.jsp.jspPageContext"; jsp/PageContext.java:151:public static final String REQUEST = "javax.servlet.jsp.jspRequest"; jsp/PageContext.java:157:public static final String RESPONSE = "javax.servlet.jsp.jspResponse"; jsp/PageContext.java:163:public static final String CONFIG = "javax.servlet.jsp.jspConfig"; jsp/PageContext.java:169:public static final String SESSION = "javax.servlet.jsp.jspSession"; jsp/PageContext.java:174:public static final String OUT = "javax.servlet.jsp.jspOut"; jsp/PageContext.java:180:public static final String APPLICATION = "javax.servlet.jsp.jspApplication"; jsp/PageContext.java:187:public static final String EXCEPTION = "javax.servlet.jsp.jspException"; RequestDispatcher.java:47:static final String FORWARD_REQUEST_URI = "javax.servlet.forward.request_uri"; RequestDispatcher.java:58:static final String FORWARD_CONTEXT_PATH = "javax.servlet.forward.context_path"; RequestDispatcher.java:69:static final String FORWARD_MAPPING = "javax.servlet.forward.mapping"; RequestDispatcher.java:80:static final String FORWARD_PATH_INFO = "javax.servlet.forward.path_info"; RequestDispatcher.java:91:static final String FORWARD_SERVLET_PATH = "javax.servlet.forward.servlet_path"; RequestDispatcher.java:102:static final String FORWARD_QUERY_STRING = "javax.servlet.forward.query_string"; RequestDispatcher.java:114:static final String INCLUDE_REQUEST_URI = "javax.servlet.include.request_uri"; RequestDispatcher.java:126:static final String INCLUDE_CONTEXT_PATH = "javax.servlet.include.context_path"; RequestDispatcher.java:138:static final String INCLUDE_PATH_INFO = "javax.servlet.include.path_info"; RequestDispatcher.java:150:static final String INCLUDE_MAPPING = "javax.servlet.include.mapping"; RequestDispatcher.java:162:static final String INCLUDE_SERVLET_PATH = "javax.servlet.include.servlet_path"; RequestDispatcher.java:174:static final String INCLUDE_QUERY_STRING = "javax.servlet.include.query_string"; RequestDispatcher.java:184:public static final String ERROR_EXCEPTION = "javax.servlet.error.exception"; RequestDispatcher.java:194:public static final String ERROR_EXCEPTION_TYPE = "javax.servlet.error.exception_type"; RequestDispatcher.java:204:public static final String ERROR_MESSAGE = "javax.servlet.error.message"; RequestDispatcher.java:214:public static final String ERROR_REQUEST_URI = "javax.servlet.error.request_uri"; RequestDispatcher.java:224:public static final String ERROR_SERVLET_NAME = "javax.servlet.error.servlet_name"; RequestDispatcher.java:234:public static final String ERROR_STATUS_CODE = "javax.servlet.error.status_code"; ServletContext.java:58:public static final String TEMPDIR = "javax.servlet.context.tempdir"; ServletContext.java:66:public static final String ORDERED_LIBS = "javax.servlet.context.orderedLibs"; ]]] 7. If you look into implementation of org.apach
Re: HTTP/2 priorities
вт, 6 дек. 2022 г. в 19:21, Mark Thomas : > > Hi all, > > I plan to implement RFC 9218 [1] for HTTP/2 in Tomcat 11. Depending on > how that goes, I may back-port the changes. > > Given the difficulties we have in prioritizing creation of responses, I > plan to continue the current approach of prioritizing the sending of > data when the connection window size is smaller than the currently > active streams have collectively requested. > > My rough plan at this stage, which is likely to change as I work through > the implementation, is: > > - remove all the code that supports the current priority tree approach > - include SETTINGS_NO_RFC7540_PRIORITIES in the initial settings > - implement the new priority scheme - expected to be a much simpler >algorithm in Http2UpgradeHandler.allocate() > > Mark > [1] https://www.rfc-editor.org/rfc/rfc9218.html#name-priority-parameters +1 Sounds reasonable. I added a link to [1] to our Specifications page on the wiki, https://cwiki.apache.org/confluence/display/TOMCAT/Specifications Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 01/04: Add NO_RFC7540_PRIORITIES setting to enum
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 9b77958b062f224bf56f2ceca5cbd2d55d3da67b Author: Mark Thomas AuthorDate: Tue Dec 6 18:00:48 2022 + Add NO_RFC7540_PRIORITIES setting to enum --- java/org/apache/coyote/http2/Setting.java | 4 1 file changed, 4 insertions(+) diff --git a/java/org/apache/coyote/http2/Setting.java b/java/org/apache/coyote/http2/Setting.java index 54b99dacba..29dc73f201 100644 --- a/java/org/apache/coyote/http2/Setting.java +++ b/java/org/apache/coyote/http2/Setting.java @@ -23,6 +23,7 @@ enum Setting { INITIAL_WINDOW_SIZE(4), MAX_FRAME_SIZE(5), MAX_HEADER_LIST_SIZE(6), +NO_RFC7540_PRIORITIES(9), UNKNOWN(Integer.MAX_VALUE); private final int id; @@ -60,6 +61,9 @@ enum Setting { case 6: { return MAX_HEADER_LIST_SIZE; } +case 9: { +return NO_RFC7540_PRIORITIES; +} default: { return Setting.UNKNOWN; } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 02/04: Send setting to disable RFC 7540 settings by default
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 500ab744ee096dae4a876994f47a19c7bfe04494 Author: Mark Thomas AuthorDate: Tue Dec 6 18:05:38 2022 + Send setting to disable RFC 7540 settings by default --- java/org/apache/coyote/http2/ConnectionSettingsBase.java | 16 java/org/apache/coyote/http2/LocalStrings.properties | 1 + 2 files changed, 17 insertions(+) diff --git a/java/org/apache/coyote/http2/ConnectionSettingsBase.java b/java/org/apache/coyote/http2/ConnectionSettingsBase.java index ef4a20010a..bd880f669f 100644 --- a/java/org/apache/coyote/http2/ConnectionSettingsBase.java +++ b/java/org/apache/coyote/http2/ConnectionSettingsBase.java @@ -45,6 +45,9 @@ abstract class ConnectionSettingsBase { static final int DEFAULT_MAX_FRAME_SIZE = MIN_MAX_FRAME_SIZE; static final long DEFAULT_MAX_HEADER_LIST_SIZE = 1 << 15; +// Defaults (defined by Tomcat) +static final long DEFAULT_NO_RFC7540_PRIORITIES = 1; + Map current = new ConcurrentHashMap<>(); Map pending = new ConcurrentHashMap<>(); @@ -58,6 +61,7 @@ abstract class ConnectionSettingsBase { current.put(Setting.INITIAL_WINDOW_SIZE, Long.valueOf(DEFAULT_INITIAL_WINDOW_SIZE)); current.put(Setting.MAX_FRAME_SIZE, Long.valueOf(DEFAULT_MAX_FRAME_SIZE)); current.put(Setting.MAX_HEADER_LIST_SIZE, Long.valueOf(DEFAULT_MAX_HEADER_LIST_SIZE)); +current.put(Setting.NO_RFC7540_PRIORITIES, Long.valueOf(DEFAULT_NO_RFC7540_PRIORITIES)); } @@ -86,6 +90,9 @@ abstract class ConnectionSettingsBase { case MAX_HEADER_LIST_SIZE: // No further validation required break; +case NO_RFC7540_PRIORITIES: +validateNoRfc7540Priorities(value); +break; case UNKNOWN: // Unrecognised. Ignore it. return; @@ -212,6 +219,15 @@ abstract class ConnectionSettingsBase { } +private void validateNoRfc7540Priorities(long noRfc7540Priorities) throws T { +if (noRfc7540Priorities < 0 || noRfc7540Priorities > 1) { +String msg = sm.getString("connectionSettings.noRfc7540PrioritiesInvalid", +connectionId, Long.toString(noRfc7540Priorities)); +throwException(msg, Http2Error.PROTOCOL_ERROR); +} +} + + abstract void throwException(String msg, Http2Error error) throws T; abstract String getEndpointName(); diff --git a/java/org/apache/coyote/http2/LocalStrings.properties b/java/org/apache/coyote/http2/LocalStrings.properties index 8972c4fb6e..7587a86f33 100644 --- a/java/org/apache/coyote/http2/LocalStrings.properties +++ b/java/org/apache/coyote/http2/LocalStrings.properties @@ -26,6 +26,7 @@ connectionSettings.debug=Connection [{0}], Endpoint [{1}], Parameter type [{2}] connectionSettings.enablePushInvalid=Connection [{0}], The requested value for enable push [{1}] is not one of the permitted values (zero or one) connectionSettings.headerTableSizeLimit=Connection [{0}], Attempted to set a header table size of [{1}] but the limit is 16k connectionSettings.maxFrameSizeInvalid=Connection [{0}], The requested maximum frame size of [{1}] is outside the permitted range of [{2}] to [{3}] +connectionSettings.noRfc7540PrioritiesInvalid=Connection [{0}], The requested no RFC 7540 priorities setting [{1}] was not zero or one connectionSettings.unknown=Connection [{0}], An unknown setting with identifier [{1}] and value [{2}] was ignored connectionSettings.windowSizeTooBig=Connection [{0}], The requested window size of [{1}] is bigger than the maximum permitted value of [{2}] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 03/04: Ensure RFC 7540 priorities are not re-enabled
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 0ae556edfa9f59ff96922b5a02dbecf58710d307 Author: Mark Thomas AuthorDate: Tue Dec 6 18:14:00 2022 + Ensure RFC 7540 priorities are not re-enabled --- java/org/apache/coyote/http2/Http2UpgradeHandler.java | 5 + java/org/apache/coyote/http2/LocalStrings.properties | 1 + 2 files changed, 6 insertions(+) diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java b/java/org/apache/coyote/http2/Http2UpgradeHandler.java index 8d402c64b9..c89fe44c1f 100644 --- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java +++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java @@ -1835,6 +1835,11 @@ class Http2UpgradeHandler extends AbstractStream implements InternalHttpUpgradeH h2e.getError(), stream.getIdAsInt())); } } +} else if (setting == Setting.NO_RFC7540_PRIORITIES) { +// This should not be changed after the initial setting +if (value != ConnectionSettingsBase.DEFAULT_NO_RFC7540_PRIORITIES) { +throw new ConnectionException(sm.getString("upgradeHandler.enableRfc7450Priorities", connectionId), Http2Error.PROTOCOL_ERROR); +} } else { remoteSettings.set(setting, value); } diff --git a/java/org/apache/coyote/http2/LocalStrings.properties b/java/org/apache/coyote/http2/LocalStrings.properties index 7587a86f33..7f7bf3a8c6 100644 --- a/java/org/apache/coyote/http2/LocalStrings.properties +++ b/java/org/apache/coyote/http2/LocalStrings.properties @@ -148,6 +148,7 @@ upgradeHandler.pruned=Connection [{0}] Pruned completed stream [{1}] upgradeHandler.prunedPriority=Connection [{0}] Pruned unused stream [{1}] that may have been part of the priority tree upgradeHandler.releaseBacklog=Connection [{0}], Stream [{1}] released from backlog upgradeHandler.reset.receive=Connection [{0}], Stream [{1}], Reset received due to [{2}] +upgradeHandler.enableRfc7450Priorities=Connection [{0}], RFC 7450 priorities may not be enabled after being disabled in the initial connection settings frame (see RFC 9218) upgradeHandler.rst.debug=Connection [{0}], Stream [{1}], Error [{2}], Message [{3}], RST (closing stream) upgradeHandler.sendPrefaceFail=Connection [{0}], Failed to send preface to client upgradeHandler.sendfile.reservation=Connection [{0}], Stream [{1}], Connection reservation [{2}], Stream reservation [{3}] prior to sendfile write - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch rfc9218 created (now 99d874f067)
This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git at 99d874f067 Don't process priority frames This branch includes the following new commits: new 9b77958b06 Add NO_RFC7540_PRIORITIES setting to enum new 500ab744ee Send setting to disable RFC 7540 settings by default new 0ae556edfa Ensure RFC 7540 priorities are not re-enabled new 99d874f067 Don't process priority frames The 4 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. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] 04/04: Don't process priority frames
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 99d874f067499fe7053d6053ad1212d91d7e8e17 Author: Mark Thomas AuthorDate: Tue Dec 6 19:16:41 2022 + Don't process priority frames --- java/org/apache/coyote/http2/Http2Parser.java | 39 +++--- .../apache/coyote/http2/Http2UpgradeHandler.java | 31 ++--- .../apache/coyote/http2/LocalStrings.properties| 1 - .../apache/coyote/http2/LocalStrings_fr.properties | 1 - .../apache/coyote/http2/LocalStrings_ja.properties | 1 - .../apache/coyote/http2/LocalStrings_ko.properties | 1 - .../coyote/http2/LocalStrings_zh_CN.properties | 1 - test/org/apache/coyote/http2/Http2TestBase.java| 13 8 files changed, 20 insertions(+), 68 deletions(-) diff --git a/java/org/apache/coyote/http2/Http2Parser.java b/java/org/apache/coyote/http2/Http2Parser.java index 60669491d5..a68ce25dcb 100644 --- a/java/org/apache/coyote/http2/Http2Parser.java +++ b/java/org/apache/coyote/http2/Http2Parser.java @@ -254,12 +254,8 @@ class Http2Parser { Integer.toString(payloadSize)), Http2Error.PROTOCOL_ERROR); } } -if (priority) { -boolean exclusive = ByteUtil.isBit7Set(optional[optionalPos]); -int parentStreamId = ByteUtil.get31Bits(optional, optionalPos); -int weight = ByteUtil.getOneByte(optional, optionalPos + 4) + 1; -output.reprioritise(streamId, parentStreamId, exclusive, weight); -} + +// Ignore RFC 7450 priority data if present payloadSize -= optionalLen; payloadSize -= padLength; @@ -277,24 +273,15 @@ class Http2Parser { } -protected void readPriorityFrame(int streamId, ByteBuffer buffer) throws Http2Exception, IOException { -byte[] payload = new byte[5]; -if (buffer == null) { -input.fill(true, payload); -} else { -buffer.get(payload); -} - -boolean exclusive = ByteUtil.isBit7Set(payload[0]); -int parentStreamId = ByteUtil.get31Bits(payload, 0); -int weight = ByteUtil.getOneByte(payload, 4) + 1; - -if (streamId == parentStreamId) { -throw new StreamException(sm.getString("http2Parser.processFramePriority.invalidParent", -connectionId, Integer.valueOf(streamId)), Http2Error.PROTOCOL_ERROR, streamId); +protected void readPriorityFrame(int streamId, ByteBuffer buffer) throws IOException { +// RFC 7450 priority frames are ignored. Still need to treat as overhead. +try { +swallowPayload(streamId, FrameType.PRIORITY.getId(), 5, false, buffer); +} catch (ConnectionException e) { +// Will never happen because swallowPayload() is called with isPadding set +// to false } - -output.reprioritise(streamId, parentStreamId, exclusive, weight); +output.increaseOverheadCount(FrameType.PRIORITY); } @@ -780,10 +767,6 @@ class Http2Parser { void headersContinue(int payloadSize, boolean endOfHeaders); void headersEnd(int streamId) throws Http2Exception; -// Priority frames (also headers) -void reprioritise(int streamId, int parentStreamId, boolean exclusive, int weight) -throws Http2Exception; - // Reset frames void reset(int streamId, long errorCode) throws Http2Exception; @@ -815,5 +798,7 @@ class Http2Parser { * frame */ void onSwallowedUnknownFrame(int streamId, int frameTypeId, int flags, int size) throws IOException; + +void increaseOverheadCount(FrameType frameType); } } diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java b/java/org/apache/coyote/http2/Http2UpgradeHandler.java index c89fe44c1f..a2405994a8 100644 --- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java +++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java @@ -1489,7 +1489,8 @@ class Http2UpgradeHandler extends AbstractStream implements InternalHttpUpgradeH } -private void increaseOverheadCount(FrameType frameType) { +@Override +public void increaseOverheadCount(FrameType frameType) { // An overhead frame increases the overhead count by // overheadCountFactor. By default, this means an overhead frame // increases the overhead count by 10. A simple browser request is @@ -1708,34 +1709,6 @@ class Http2UpgradeHandler extends AbstractStream implements InternalHttpUpgradeH } -@Override -public void reprioritise(int streamId, int parentStreamId, -boolean exclusive, int weight) throws Http2Exception { -if (streamId == parentStreamId) { -throw new ConnectionException(sm.
Re: [tomcat] branch rfc9218 created (now 99d874f067)
Sorry. Didn't mean to push this. I think I clicked the wrong button in my IDE out of habit. Mark On 06/12/2022 19:16, ma...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch rfc9218 in repository https://gitbox.apache.org/repos/asf/tomcat.git at 99d874f067 Don't process priority frames This branch includes the following new commits: new 9b77958b06 Add NO_RFC7540_PRIORITIES setting to enum new 500ab744ee Send setting to disable RFC 7540 settings by default new 0ae556edfa Ensure RFC 7540 priorities are not re-enabled new 99d874f067 Don't process priority frames The 4 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. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Preparing to migrate to Tomcat 10.1 / Jakarta EE
On Tue, Dec 6, 2022 at 6:48 PM Konstantin Kolinko wrote: > > пн, 5 дек. 2022 г. в 23:32, Christopher Schultz > : > > > > All, > > > > I've started looking at the migration path at $work for Jakarta EE and > > while Tomcat 10 has some fantastic features to help with that (hot > > migration is killer IMO), there are still some potential barriers I'm > > seeing to "slowly" migrating $work applications from Java EE -> Jakarta EE. > > > > When I say "slowly", I mean "not having to write one or more large > > revision-control changes to lock-step-upgrade from e.g. Tomcat 8/9 to > > Tomcat 10.1." > > > > One specific example is that we use Apache Velocity as our > > page-generation language and AIUI, these templates will not have their > > text scanned and replaced with updated strings. For example: > > > > #if($request.getAttribute('javax.servlet.error.request_uri')) > > ... > > #end > > > > [... skipped] > > > > I can think of a few ways to facilitate a dual-deployment (Tomcat 8/9 vs > > 10 aka Java EE vs Jakarta EE) application, at least for the specific > > example I present above: > > > > [... skipped] > > 6. I think that Migration Tool can be updated to change string > constants such as the above one. It should do that here: https://github.com/apache/tomcat-jakartaee-migration/blob/main/src/main/java/org/apache/tomcat/jakartaee/TextConverter.java You can see the extensions that are processed in the source. However, there are some limitations, like the string has to appear as a whole in the file, and so on. Although not strictly compliant, it could be worthwhile to consider attributes names starting with "javax." as if they started with "jakarta.". Rémy > There is a limited set of those names, and I expect them to always > appear as a whole string among string constants. > > Going into java/javax/servlet of Tomcat 9 and running a search for `"javax.`, > except '.LocalStrings"' l10n resources names: > > grep --line-number --recursive '"javax.' | grep --invert-match > '.LocalStrings"' - >../found.txt > > I get the following 36 lines: > > [[[ > AsyncContext.java:30:"javax.servlet.async.request_uri"; > AsyncContext.java:36:"javax.servlet.async.context_path"; > AsyncContext.java:42:"javax.servlet.async.mapping"; > AsyncContext.java:48:"javax.servlet.async.path_info"; > AsyncContext.java:54:"javax.servlet.async.servlet_path"; > AsyncContext.java:60:"javax.servlet.async.query_string"; > jsp/PageContext.java:139:public static final String PAGE = > "javax.servlet.jsp.jspPage"; > jsp/PageContext.java:145:public static final String PAGECONTEXT = > "javax.servlet.jsp.jspPageContext"; > jsp/PageContext.java:151:public static final String REQUEST = > "javax.servlet.jsp.jspRequest"; > jsp/PageContext.java:157:public static final String RESPONSE = > "javax.servlet.jsp.jspResponse"; > jsp/PageContext.java:163:public static final String CONFIG = > "javax.servlet.jsp.jspConfig"; > jsp/PageContext.java:169:public static final String SESSION = > "javax.servlet.jsp.jspSession"; > jsp/PageContext.java:174:public static final String OUT = > "javax.servlet.jsp.jspOut"; > jsp/PageContext.java:180:public static final String APPLICATION = > "javax.servlet.jsp.jspApplication"; > jsp/PageContext.java:187:public static final String EXCEPTION = > "javax.servlet.jsp.jspException"; > RequestDispatcher.java:47:static final String FORWARD_REQUEST_URI > = "javax.servlet.forward.request_uri"; > RequestDispatcher.java:58:static final String FORWARD_CONTEXT_PATH > = "javax.servlet.forward.context_path"; > RequestDispatcher.java:69:static final String FORWARD_MAPPING = > "javax.servlet.forward.mapping"; > RequestDispatcher.java:80:static final String FORWARD_PATH_INFO = > "javax.servlet.forward.path_info"; > RequestDispatcher.java:91:static final String FORWARD_SERVLET_PATH > = "javax.servlet.forward.servlet_path"; > RequestDispatcher.java:102:static final String > FORWARD_QUERY_STRING = "javax.servlet.forward.query_string"; > RequestDispatcher.java:114:static final String INCLUDE_REQUEST_URI > = "javax.servlet.include.request_uri"; > RequestDispatcher.java:126:static final String > INCLUDE_CONTEXT_PATH = "javax.servlet.include.context_path"; > RequestDispatcher.java:138:static final String INCLUDE_PATH_INFO = > "javax.servlet.include.path_info"; > RequestDispatcher.java:150:static final String INCLUDE_MAPPING = > "javax.servlet.include.mapping"; > RequestDispatcher.java:162:static final String > INCLUDE_SERVLET_PATH = "javax.servlet.include.servlet_path"; > RequestDispatcher.java:174:static final String > INCLUDE_QUERY_STRING = "javax.servlet.include.query_string"; > RequestDispatcher.java:184:public static final String > ERROR_EXCEPTION = "javax.servlet.error.exception"; > RequestDispatcher.java:194:public static final String > ERROR_EXCEPTION_TYPE = "javax.servlet.error.except
Re: Preparing to migrate to Tomcat 10.1 / Jakarta EE
Rémy, On 12/6/22 16:42, Rémy Maucherat wrote: On Tue, Dec 6, 2022 at 6:48 PM Konstantin Kolinko wrote: пн, 5 дек. 2022 г. в 23:32, Christopher Schultz : All, I've started looking at the migration path at $work for Jakarta EE and while Tomcat 10 has some fantastic features to help with that (hot migration is killer IMO), there are still some potential barriers I'm seeing to "slowly" migrating $work applications from Java EE -> Jakarta EE. When I say "slowly", I mean "not having to write one or more large revision-control changes to lock-step-upgrade from e.g. Tomcat 8/9 to Tomcat 10.1." One specific example is that we use Apache Velocity as our page-generation language and AIUI, these templates will not have their text scanned and replaced with updated strings. For example: #if($request.getAttribute('javax.servlet.error.request_uri')) ... #end [... skipped] I can think of a few ways to facilitate a dual-deployment (Tomcat 8/9 vs 10 aka Java EE vs Jakarta EE) application, at least for the specific example I present above: [... skipped] 6. I think that Migration Tool can be updated to change string constants such as the above one. Does this happen at the "source" level? For example, if I have .jsp files does it search-and-replace .jsp source, or only the resulting .class files. Does this work with the on-the-fly migration, or only with the "offline" tool? I'm happy to simply add *.vm to the list of things we process. That would actually be a good and simple fix for both me and potentially others looking to upgrade. It should do that here: https://github.com/apache/tomcat-jakartaee-migration/blob/main/src/main/java/org/apache/tomcat/jakartaee/TextConverter.java You can see the extensions that are processed in the source. However, there are some limitations, like the string has to appear as a whole in the file, and so on. Although not strictly compliant, it could be worthwhile to consider attributes names starting with "javax." as if they started with "jakarta.". This limitation isn't a problem for me: we always use "full strings" for those kinds of things. Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-training] dependabot[bot] opened a new pull request, #11: Bump qs
dependabot[bot] opened a new pull request, #11: URL: https://github.com/apache/tomcat-training/pull/11 Bumps [qs](https://github.com/ljharb/qs) and [qs](https://github.com/ljharb/qs). These dependencies needed to be updated together. Updates `qs` from 6.5.1 to 6.5.3 Changelog Sourced from https://github.com/ljharb/qs/blob/main/CHANGELOG.md";>qs's changelog. 6.5.3 [Fix] parse: ignore __proto__ keys (https://github-redirect.dependabot.com/ljharb/qs/issues/428";>#428) [Fix] utils.merge`: avoid a crash with a null target and a truthy non-array source [Fix] correctly parse nested arrays [Fix] stringify: fix a crash with strictNullHandling and a custom filter/serializeDate (https://github-redirect.dependabot.com/ljharb/qs/issues/279";>#279) [Fix] utils: merge: fix crash when source is a truthy primitive & no options are provided [Fix] when parseArrays is false, properly handle keys ending in [] [Fix] fix for an impossible situation: when the formatter is called with a non-string value [Fix] utils.merge: avoid a crash with a null target and an array source [Refactor] utils: reduce observable [[Get]]s [Refactor] use cached Array.isArray [Refactor] stringify: Avoid arr = arr.concat(...), push to the existing instance (https://github-redirect.dependabot.com/ljharb/qs/issues/269";>#269) [Refactor] parse: only need to reassign the var once [Robustness] stringify: avoid relying on a global undefined (https://github-redirect.dependabot.com/ljharb/qs/issues/427";>#427) [readme] remove travis badge; add github actions/codecov badges; update URLs [Docs] Clean up license text so it’s properly detected as BSD-3-Clause [Docs] Clarify the need for "arrayLimit" option [meta] fix README.md (https://github-redirect.dependabot.com/ljharb/qs/issues/399";>#399) [meta] add FUNDING.yml [actions] backport actions from main [Tests] always use String(x) over x.toString() [Tests] remove nonexistent tape option [Dev Deps] backport from main 6.5.2 [Fix] use safer-buffer instead of Buffer constructor [Refactor] utils: module.exports one thing, instead of mutating exports (https://github-redirect.dependabot.com/ljharb/qs/issues/230";>#230) [Dev Deps] update browserify, eslint, iconv-lite, safer-buffer, tape, browserify Commits https://github.com/ljharb/qs/commit/298bfa55d6db00ddea78dd0333509aadf9bb3077";>298bfa5 v6.5.3 https://github.com/ljharb/qs/commit/ed0f5dcbef4b168a8ae299d78b1e4a2e9b1baf1f";>ed0f5dc [Fix] parse: ignore __proto__ keys (https://github-redirect.dependabot.com/ljharb/qs/issues/428";>#428) https://github.com/ljharb/qs/commit/691e739cfa40cd42604dc05a54e6154371a429ab";>691e739 [Robustness] stringify: avoid relying on a global undefined (https://github-redirect.dependabot.com/ljharb/qs/issues/427";>#427) https://github.com/ljharb/qs/commit/1072d57d38a690e1ad7616dced44390bffedcbb2";>1072d57 [readme] remove travis badge; add github actions/codecov badges; update URLs https://github.com/ljharb/qs/commit/12ac1c403aaa04d1a34844f514ed9f9abfb76e64";>12ac1c4 [meta] fix README.md (https://github-redirect.dependabot.com/ljharb/qs/issues/399";>#399) https://github.com/ljharb/qs/commit/0338716b09fdbd4711823eeb0a14e556a2498e7a";>0338716 [actions] backport actions from main https://github.com/ljharb/qs/commit/5639c20ce0a7c1332200a3181339331483e5a3a1";>5639c20 Clean up license text so it’s properly detected as BSD-3-Clause https://github.com/ljharb/qs/commit/51b8a0b1b213596dd1702b837f5e7dec2229793d";>51b8a0b add FUNDING.yml https://github.com/ljharb/qs/commit/45f675936e742d92fac8d4dae5cfc385c576a977";>45f6759 [Fix] fix for an impossible situation: when the formatter is called with a no... https://github.com/ljharb/qs/commit/f814a7f8f2af059f8158f7e4b2bf8b46aeb62cd3";>f814a7f [Dev Deps] backport from main Additional commits viewable in https://github.com/ljharb/qs/compare/v6.5.1...v6.5.3";>compare view Updates `qs` from 6.3.2 to 6.5.3 Changelog Sourced from https://github.com/ljharb/qs/blob/main/CHANGELOG.md";>qs's changelog. 6.5.3 [Fix] parse: ignore __proto__ keys (https://github-redirect.dependabot.com/ljharb/qs/issues/428";>#428) [Fix] utils.merge`: avoid a crash with a null target and a truthy non-array source [Fix] correctly parse nested arrays [Fix] stringify: fix a crash with strictNullHandling and a custom filter/serializeDate (https://github-redirect.dependabot.com/ljharb/qs/issues/279";>#279) [Fix] utils: merge: fix crash when source is a truthy primitive & no options are provided [Fix] when parseArrays is false, properly handle keys ending in [] [Fix] fix for an impossible situation: when the formatter is called with a non-string value [Fix] utils.merge: avoid a crash with a null target and an array source [Refactor] utils: reduce observable [[Get]]s [Refa
[tomcat-training] branch dependabot/npm_and_yarn/qs-and-qs-6.5.3 created (now 81eed17)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/npm_and_yarn/qs-and-qs-6.5.3 in repository https://gitbox.apache.org/repos/asf/tomcat-training.git at 81eed17 Bump qs No new revisions were added by this update. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Regarding Compilation Steps for Tomcat version 9 on RHEL8
Hi, We have downloaded Tomcat version 9 "apache-tomcat-9.0.70.tar.gz" from https://tomcat.apache.org/download-90.cgi. To check the compatibility of Tomcat version 9.0 with OpenSSL 3.0, we need to compile source code of Tomcat version 9 on RHEL-8 with OpenSSL3.0. We require compilation steps to compile Tomcat source code on RHEL8. Could you please help to share the compilation steps? Regards Vivek Singh Naruka