Re: POST request fails if content is ignored?
Thank you for the suggestion. I have just tried playing with this value. Setting it to -1, and setting it to 100x larger than the default. In both cases, the behaviour seems unchanged. Without touching this value, Tomcat will accept multipart POST requests much larger than 2MB (which is the default) as long as you call request.getPart() or request.getParameter(). The problem I am seeing is that if a response is sent without calling one of those methods, the browsers see it as a failed request. Thanks On 09/09/2019 12:59, André Warnier (tomcat) wrote: > Hi. > Did you check : > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes > > --> maxPostSize > > Note : normally, the browser will encode (Base64 or similar) the > content of a file and send the encoded content, which tends to be > significantly larger (in bytes) than the original file (say + 30%). I > do not know (and the doc does not say) if the maxPostSize attribute > refers to the POST content still encoded or already decoded. > > > On 09.09.2019 12:53, Leon Atherton wrote: >> Hello, >> >> I've discovered an interesting issue where POST requests fail when >> uploading a file over about ~6MB if the server ignores the request >> content. >> >> I've put together a simple project to reproduce it: >> https://github.com/leonatherton/tomcat-request-issue >> >> Serverside code: >> https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java >> >> >> Clientside code: >> https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html >> >> >> >> If you'd like to try it yourself there are a couple of pre-built war >> files on the releases page, and there are steps to reproduce in the >> README.md file. >> >> The problem does not occur when uploading a small file, and the problem >> can be "fixed" by simply getting a parameter from the request object. It >> reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara, >> but I am seeing similar on Jetty. >> >> My guess is that the server responds before the client has finished >> uploading the file. The browsers see the incomplete upload and report >> this as an error, despite content being sent in response. And my guess >> is that inspecting a request parameter causes the server to wait for the >> full upload before sending the response. >> >> It's a slightly odd workflow, but it's not too unreasonable to sometimes >> respond early and ignore the request content. >> >> Is this expected behavior, or a bug in Tomcat? >> >> Thanks! >> Leon >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
POST request fails if content is ignored?
Hello, I've discovered an interesting issue where POST requests fail when uploading a file over about ~6MB if the server ignores the request content. I've put together a simple project to reproduce it: https://github.com/leonatherton/tomcat-request-issue Serverside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java Clientside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html If you'd like to try it yourself there are a couple of pre-built war files on the releases page, and there are steps to reproduce in the README.md file. The problem does not occur when uploading a small file, and the problem can be "fixed" by simply getting a parameter from the request object. It reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara, but I am seeing similar on Jetty. My guess is that the server responds before the client has finished uploading the file. The browsers see the incomplete upload and report this as an error, despite content being sent in response. And my guess is that inspecting a request parameter causes the server to wait for the full upload before sending the response. It's a slightly odd workflow, but it's not too unreasonable to sometimes respond early and ignore the request content. Is this expected behavior, or a bug in Tomcat? Thanks! Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: POST request fails if content is ignored?
Very grateful for your reply, this does indeed solve my issue (and I learned something new too). Thanks, Leon On 10/09/2019 12:03, Mark Thomas wrote: > On 09/09/2019 16:41, Leon Atherton wrote: >> Our use case is rejecting the request based on IP. >> >> In the browser the status code is 0, and the network tab in developer >> tools is showing no response to the request. It's the same in Chrome and >> Firefox. >> >> The request works fine when I send from Node.JS. >> >> It seems to me that Tomcat responds to the request before the upload has >> completed, and calling request.getParameter() fixes the problem because >> it causes Tomcat to read the full request before the response is sent. >> >> Some clients are fine with the early response (e.g. Node.JS), but both >> Chrome and Firefox don't like it. >> >> I'm not sure if it's an issue with how Tomcat handles the request, or >> how the browsers are handling the response (but I suspect it can be >> fixed on the Tomcat side as the problem does not occur with Payara). > The configuration attribute you want is maxSwallowSize. You need to set > that to greater than the size of the uploaded file. > > Clients could handle this better but many don't read the response until > the request is fully written. > > Tomcat limit's maxSwallowSize as a DoS protection measure. Without it, a > client could just continue uploading a slow trickle of data and tie up a > server thread. > > For the record, maPostSize applies *only* to requests using > application/x-www-form-urlencoded > > The test provided by the OP uses multipart/form-data. The applicable > limits are defined by javax.servlet.annotation.MultipartConfig and the > defaults are unlimited. > > Any call to getPart(), getParameter() and friends will trigger the > reading of the request body. > > Hence, without the call to getParameter() Tomcat doesn't read the > request body. With small uploads there is enough network buffering > between the client and the server for the client to be able to write the > full request so it reads the response. (Tomcat's maxSwallowSize > effectively acts as a buffer.) With larger uploads the client fills the > buffers before the request is fully written so it never sees the response. > > Increasing the maxSwallowSize will allow the client to write the full > request and then read the response. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: POST request fails if content is ignored?
Our use case is rejecting the request based on IP. In the browser the status code is 0, and the network tab in developer tools is showing no response to the request. It's the same in Chrome and Firefox. The request works fine when I send from Node.JS. It seems to me that Tomcat responds to the request before the upload has completed, and calling request.getParameter() fixes the problem because it causes Tomcat to read the full request before the response is sent. Some clients are fine with the early response (e.g. Node.JS), but both Chrome and Firefox don't like it. I'm not sure if it's an issue with how Tomcat handles the request, or how the browsers are handling the response (but I suspect it can be fixed on the Tomcat side as the problem does not occur with Payara). Thanks On 09/09/2019 15:48, André Warnier (tomcat) wrote: > On 09.09.2019 15:21, Leon Atherton wrote: >> Thank you for the suggestion. >> >> I have just tried playing with this value. Setting it to -1, and setting >> it to 100x larger than the default. >> In both cases, the behaviour seems unchanged. >> >> Without touching this value, Tomcat will accept multipart POST requests >> much larger than 2MB (which is the default) as long as you call >> request.getPart() or request.getParameter(). > > I haven't tried that, but as per the documentation that at least looks > wrong. > >> >> The problem I am seeing is that if a response is sent without calling >> one of those methods, the browsers see it as a failed request. > > To help me (or us) better understand the issue, could you provide a > bit of context ? > Such as : why would the client send content in a POST, if the service > at the end of the target URL is not going to read that content ? > What would be a use case ? > > (Mainly because my interpretation is that, if the browser does that, > then at least in some way it /is/ a bad request, which /should/ fail). > > And maybe another question : have you tried monitoring such a > request/response using a browser-based tracing tool, to show exactly > what the server is sending back ? > (is it e.g. some kind of 4xx response ?) > > >> >> Thanks >> >> On 09/09/2019 12:59, André Warnier (tomcat) wrote: >>> Hi. >>> Did you check : >>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes >>> >>> >>> --> maxPostSize >>> >>> Note : normally, the browser will encode (Base64 or similar) the >>> content of a file and send the encoded content, which tends to be >>> significantly larger (in bytes) than the original file (say + 30%). I >>> do not know (and the doc does not say) if the maxPostSize attribute >>> refers to the POST content still encoded or already decoded. >>> >>> >>> On 09.09.2019 12:53, Leon Atherton wrote: >>>> Hello, >>>> >>>> I've discovered an interesting issue where POST requests fail when >>>> uploading a file over about ~6MB if the server ignores the request >>>> content. >>>> >>>> I've put together a simple project to reproduce it: >>>> https://github.com/leonatherton/tomcat-request-issue >>>> >>>> Serverside code: >>>> https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java >>>> >>>> >>>> >>>> Clientside code: >>>> https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html >>>> >>>> >>>> >>>> >>>> If you'd like to try it yourself there are a couple of pre-built war >>>> files on the releases page, and there are steps to reproduce in the >>>> README.md file. >>>> >>>> The problem does not occur when uploading a small file, and the >>>> problem >>>> can be "fixed" by simply getting a parameter from the request >>>> object. It >>>> reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara, >>>> but I am seeing similar on Jetty. >>>> >>>> My guess is that the server responds before the client has finished >>>> uploading the file. The browsers see the incomplete upload and report >>>> this as an error, despite content being sent in response. And my guess >>>> is that inspecting a request parameter causes the server to wait >>>> for the >>>> full upload before sending the response. >>>> >>>> It's a slightly odd workflow, but it's not too unrea
Firefox triggers HTTP2 overhead protection - known issue?
We are seeing that Firefox triggers the HTTP2 overhead protection with multipart file uploads. About 1MB is uploaded before overhead protection is triggered. I believe a few weeks ago Chrome was triggering this too, but it looks like a recent update may have resolved it. This is on Tomcat 9.0.45 (though it applies to earlier versions too) using the org.apache.coyote.http11.Http11NioProtocol connector with upgrade to org.apache.coyote.http2.Http2Protocol. With http2 debug logging enabled, there are occasional Payload size [1] interspersed between larger payloads, though it appears to be a couple of back-to-back Payload size [1]'s which may be triggering the org.apache.coyote.http2.ConnectionException: Connection [0], Too much overhead so the connection will be closed. I've found earlier Tomcat conversations which seem to indicate it's a client issue. I've searched through the Firefox bug tracker but have not found anything that looks like this (feels like looking for a needle in a haystack). Is this a known issue in Tomcat or Firefox? It can be resolved by disabling the protection or potentially just tweaking the config values, but if it's a known Firefox issue I'd like to know if something has been raised on their bug tracker I can follow? Thanks Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Firefox triggers HTTP2 overhead protection - known issue?
On 06/05/2021 16:06, Christopher Schultz wrote: On 5/6/21 09:36, Mark Thomas wrote: On 06/05/2021 13:33, Christopher Schultz wrote: Leon, On 5/6/21 06:25, Leon Atherton wrote: We are seeing that Firefox triggers the HTTP2 overhead protection with multipart file uploads. About 1MB is uploaded before overhead protection is triggered. I believe a few weeks ago Chrome was triggering this too, but it looks like a recent update may have resolved it. This is on Tomcat 9.0.45 (though it applies to earlier versions too) using the org.apache.coyote.http11.Http11NioProtocol connector with upgrade to org.apache.coyote.http2.Http2Protocol. With http2 debug logging enabled, there are occasional Payload size [1] interspersed between larger payloads, though it appears to be a couple of back-to-back Payload size [1]'s which may be triggering the org.apache.coyote.http2.ConnectionException: Connection [0], Too much overhead so the connection will be closed. I've found earlier Tomcat conversations which seem to indicate it's a client issue. I've searched through the Firefox bug tracker but have not found anything that looks like this (feels like looking for a needle in a haystack). Is this a known issue in Tomcat or Firefox? It can be resolved by disabling the protection or potentially just tweaking the config values, but if it's a known Firefox issue I'd like to know if something has been raised on their bug tracker I can follow? Nothing in the tracker that I know of off-hand, but there is this informative answer on SO by markt which may help you a little: https://stackoverflow.com/a/61454503/276232 Using the information in that answer may allow you to reconfigure your server to allow Firefox's behavior. It's probably worth us taking some time to adapt markt's SO answer there into a whole section on "Protocol Abuse and Protection Features" in the HTTP/2 configuration guide. There is an open issue for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1000809 ACK but there hasn't been much movement. I'll add something to my TODO list to see what can be done to avoid false positives like this as it looks like short sequences of small packets can occur depending on how the client buffers data. Maybe a tweak to the default settings can improve things for "the status quo" for current web browser behavior. Thanks guys. I'm currently unable to reproduce the problem in Chrome (not seeing any 1 byte payloads). I thought it reproduced a few weeks ago, but perhaps I'm misremembering. Firefox's market share isn't what it was, but it would be good if this could work out of the box - either by tweaking the Tomcat code or default config to prevent the false-positive or opening a ticket so the Firefox team know what to fix. Happy to help with the latter, though I'd need some assistance to explain the problem and expected solution. I could bore you to tears with the ins and outs of the PDF spec, but HTTP2 is not one of my specialist subjects. Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Firefox triggers HTTP2 overhead protection - known issue?
On 06/05/2021 17:13, Leon Atherton wrote: On 06/05/2021 16:06, Christopher Schultz wrote: On 5/6/21 09:36, Mark Thomas wrote: On 06/05/2021 13:33, Christopher Schultz wrote: Leon, On 5/6/21 06:25, Leon Atherton wrote: We are seeing that Firefox triggers the HTTP2 overhead protection with multipart file uploads. About 1MB is uploaded before overhead protection is triggered. I believe a few weeks ago Chrome was triggering this too, but it looks like a recent update may have resolved it. This is on Tomcat 9.0.45 (though it applies to earlier versions too) using the org.apache.coyote.http11.Http11NioProtocol connector with upgrade to org.apache.coyote.http2.Http2Protocol. With http2 debug logging enabled, there are occasional Payload size [1] interspersed between larger payloads, though it appears to be a couple of back-to-back Payload size [1]'s which may be triggering the org.apache.coyote.http2.ConnectionException: Connection [0], Too much overhead so the connection will be closed. I've found earlier Tomcat conversations which seem to indicate it's a client issue. I've searched through the Firefox bug tracker but have not found anything that looks like this (feels like looking for a needle in a haystack). Is this a known issue in Tomcat or Firefox? It can be resolved by disabling the protection or potentially just tweaking the config values, but if it's a known Firefox issue I'd like to know if something has been raised on their bug tracker I can follow? Nothing in the tracker that I know of off-hand, but there is this informative answer on SO by markt which may help you a little: https://stackoverflow.com/a/61454503/276232 Using the information in that answer may allow you to reconfigure your server to allow Firefox's behavior. It's probably worth us taking some time to adapt markt's SO answer there into a whole section on "Protocol Abuse and Protection Features" in the HTTP/2 configuration guide. There is an open issue for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1000809 ACK but there hasn't been much movement. I'll add something to my TODO list to see what can be done to avoid false positives like this as it looks like short sequences of small packets can occur depending on how the client buffers data. Maybe a tweak to the default settings can improve things for "the status quo" for current web browser behavior. Thanks guys. I'm currently unable to reproduce the problem in Chrome (not seeing any 1 byte payloads). I thought it reproduced a few weeks ago, but perhaps I'm misremembering. Firefox's market share isn't what it was, but it would be good if this could work out of the box - either by tweaking the Tomcat code or default config to prevent the false-positive or opening a ticket so the Firefox team know what to fix. Happy to help with the latter, though I'd need some assistance to explain the problem and expected solution. I could bore you to tears with the ins and outs of the PDF spec, but HTTP2 is not one of my specialist subjects. Leon Just to confirm that I have been able to reproduce this on an older build of Chromium (88.0.4324.0). Seems like it's the same issue as the current version of Firefox - consequtive 1 byte payloads triggering the overhead protection. Glad I'm not going crazy. Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ApacheCon @Home 2020 links for the presentations page
I noticed the presentations page (https://tomcat.apache.org/presentations.html) does not yet have the links from ApacheCon @Home 2020. Please find below the HTML that will correct this. I wasn't able to find links to the slides. Whilst you are there, I also noticed the legal page (https://tomcat.apache.org/legal.html) needs the copyright year updated from 2020 to 2021 in the first paragraph. Regards, Leon --- ApacheCon @Home 2020 State of the Cat - Mark Thomas, https://www.youtube.com/watch?v=uDy-Dwexy2Q;>video Lost in the Docs - Felix Schumacher, https://www.youtube.com/watch?v=pSU0l5kbcJ8;>video Deploying a Production Instance - Andrew Carr, https://www.youtube.com/watch?v=V75wPfhYsj4;>video HTTP/2, HTTP/3, and SSL/TLS State of the Art in our Servers (httpd, Traffic Server, and Tomcat) - Jean-Frederic Clere, https://www.youtube.com/watch?v=xzqOU6ILJzQ;>video Split your Tomcat Installation for Easier Upgrades - Christopher Schultz, https://www.youtube.com/watch?v=nu229pb09D0;>video Tomcat: New and Upcoming - Rmy Mucherat, https://www.youtube.com/watch?v=L5PFoJyS-aU;>video Reverse-Proxying with nginx - Igal Sapir, https://www.youtube.com/watch?v=8e1V9tVwNR8;>video Tomcat: From a Cluster to a Cloud - Jean-Frederic Clere, https://www.youtube.com/watch?v=COsTWphp2fk;>video Migrating from AJP to HTTP: It's About Time - Christopher Schultz, https://www.youtube.com/watch?v=qUjUEvGFstI;>video Tomcat 10 and Jakarta EE - Mark Thomas, https://www.youtube.com/watch?v=10PkrWRPgPU;>video Getting Started Hacking Tomcat - Christopher Schultz, https://www.youtube.com/watch?v=O2wXAldxQWA;>video Apache Tomcat and Spring Boot - Andrew Carr, https://www.youtube.com/watch?v=Nk-rKXQC0BU;>video Openly Handling Security Vulnerabilities (Q/Panel) - Mark Thomas, Christopher Schultz, Coty Sutherland, https://www.youtube.com/watch?v=tGjyX6meGcA;>video - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Is RMI leak prevention working properly? Shutdown failure
Hello, I have observed that the Tomcat process does not shut down properly when the RMI leak prevention is triggered. The process remains alive and holds onto the RMI port. I have created this sample project to demonstrate the issue: https://github.com/leonatherton/rmi-leak-test/blob/master/src/main/java/rmi/RmiLeakTestServlet.java There are prebuilt wars here: https://github.com/leonatherton/rmi-leak-test/releases/tag/v0.0.0 Steps to reproduce: 1. Deploy the war (rmi-leak-test.war) 2. Trigger a shutdown 3. Observe that the process does not end, and holds on to the RMI port (can be seen with netstat -tulpn) This message is logged: SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets Found RMI Target with stub class class [com.sun.proxy.$Proxy5] and value [Proxy[MyRemote,RemoteObjectInvocationHandler[UnicastRef [liveRef: [endpoint:[127.0.0.1:46013](local),objID:[-30127669:18b42a65f21:-7fff, 8331338290308659576]]. This RMI Target has been forcibly removed to prevent a memory leak. Tomcat obviously tries to tidy up, but it seems like maybe not successfully. I am wondering if it is expected behaviour for the process to remain alive? Full log below. Thanks, Leon NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 18-Oct-2023 11:57:59.621 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.73 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Feb 27 2023 15:33:40 UTC 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.73.0 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 3.10.0-1160.45.1.el7.x86_64 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-11-amazon-corretto 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 11.0.20.1+9-LTS 18-Oct-2023 11:57:59.650 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Amazon.com Inc. 18-Oct-2023 11:57:59.651 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /home/converter/apache-tomcat-base 18-Oct-2023 11:57:59.651 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /home/converter/apache-tomcat-9.0.73 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 18-Oct-2023 11:57:59.669 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/home/converter/apache-tomcat-base//conf/logging.properties 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs= 18-Oct-2023 11:57:59.670 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument:
