Re: Unexpected behavior of filters
вт, 16 апр. 2024 г. в 22:42, Christopher Schultz : > > [...] > > 2. Abort this stupid idea and do something else URLs that end with ".do" always remind me about this old page: https://www.w3.org/Provider/Style/URI Cool URIs don't change (c)1998 Tim BL Though you might have already seen it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unexpected behavior of filters
Konstantin, On 4/16/24 13:16, Konstantin Kolinko wrote: вт, 16 апр. 2024 г. в 18:17, Christopher Schultz : All, I'm not sure if this is the first time I've tried something like this, but I was surprised by the behavior I observed today when trying to configure a new Filter. I have an existing Filter that looks at Cookies provided in a request. I wanted to add a new Filter that takes request parameters and returns them from request.getCookies() but only for a small number of URL patterns which we handle only internally, both for security (?) and also for performance, since this isn't a really common thing for us to do. So I have these two filters: cookieUserFilter ... cookieParameterFilter ... cookieParameterFilter *.xml.do /some/specific/pattern cookieUserFilter *.do *.jsp I have tested that both Filters work as expected when called. However, when I configure them as above and request /foo.xml.do, only the cookieUserFilter is being called. The cookieParameterFilter is not being called. [...] What am I missing? This is Tomcat 9.0.85 and everything is defined in WEB-INF/web.xml. Hi, Chris! The Servlet 4.0 specification (the one that applies to Tomcat 9) says: 1) ch. 12.2 Specification of Mappings "A string beginning with a ‘ *. ’ prefix is used as an extension mapping." searching for "extension" finds: 2) ch 12.1 Use of URL Paths "3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’ . ’ character." As it says "after the last '.' character" then by this design *.xml.do cannot match anything. Aw. I suppose anything else would be terrible for performance. So the problem is that I was specifying an "extension" mapping that is not legal. I don't see anything in the log files, but this seems like a good thing to log. I'll check to see if such a thing could be added. I now have two options: 1. Specify every individual url-pattern that I want to support (which is easy: there are a very small number of them) 2. Abort this stupid idea and do something else I've already opted for #2 anyway because it's less-stupid than trying to use request parameters as a proxy for cookies. It also solves like 2 other problems at the same time, so I like my other solution better. (You may look at how o.a.catalina.mapper.Mapper actually works. Look for extensionWrappers and method internalMapExtensionWrapper().) Thanks for the pointer. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 10 clustering is not replicating session data
Hello,
I am running Tomcat 10.1.20 with Java 17
But our session data is being lost.
Here is snippet of the clustering I have defined..
Notice in sessionAttributeNameFilter that one of the session attributes I want
replicated is -> logged_in_user
We have to include the session data we want replicated here Correct?
logged_in_user is one we want replicated, its value is a String
When I run my app this code runs ->
public class Utils {
public static String getUserName( HttpServletRequest request )
{
return (String)
request.getSession().getAttribute("logged_in_user");
}
}
That code returns a null value, indicating that the session value is not found.
Does anyone see something wrong with how I defined the clustering?
This below comes from the Catalina.out log and indicates there is an issue with
clustering...
SEVERE: Manager [##0001]: No session state sent at [4/16/24, 12:48 PM]
received, timing out after [60,074] ms.
Apr 16, 2024 12:49:54 PM org.apache.catalina.ha.session.DeltaManager
getAllClusterSessions
WARNING: Manager [##0001]: Drop message [SESSION-GET-ALL] inside
GET_ALL_SESSIONS sync phase start date [4/16/24, 12:48 PM] message date
[4/16/24, 12:48 PM]
Our live environment has two app server machines being fed by one loadbalancer.
In our dev environment, that has just one machine, this same session data can
be extracted.
But not on the live 2 machine environment
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com
Re: Unexpected behavior of filters
вт, 16 апр. 2024 г. в 18:17, Christopher Schultz : > > All, > > I'm not sure if this is the first time I've tried something like this, > but I was surprised by the behavior I observed today when trying to > configure a new Filter. > > I have an existing Filter that looks at Cookies provided in a request. > > I wanted to add a new Filter that takes request parameters and returns > them from request.getCookies() but only for a small number of URL > patterns which we handle only internally, both for security (?) and also > for performance, since this isn't a really common thing for us to do. > > So I have these two filters: > > >cookieUserFilter >... > > > >cookieParameterFilter >... > > > >cookieParameterFilter >*.xml.do >/some/specific/pattern > > > >cookieUserFilter >*.do >*.jsp > > > I have tested that both Filters work as expected when called. However, > when I configure them as above and request /foo.xml.do, only the > cookieUserFilter is being called. The cookieParameterFilter is not being > called. >[...] > > What am I missing? > > This is Tomcat 9.0.85 and everything is defined in WEB-INF/web.xml. Hi, Chris! The Servlet 4.0 specification (the one that applies to Tomcat 9) says: 1) ch. 12.2 Specification of Mappings "A string beginning with a ‘ *. ’ prefix is used as an extension mapping." searching for "extension" finds: 2) ch 12.1 Use of URL Paths "3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’ . ’ character." As it says "after the last '.' character" then by this design *.xml.do cannot match anything. (You may look at how o.a.catalina.mapper.Mapper actually works. Look for extensionWrappers and method internalMapExtensionWrapper().) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Unexpected behavior of filters
All, I'm not sure if this is the first time I've tried something like this, but I was surprised by the behavior I observed today when trying to configure a new Filter. I have an existing Filter that looks at Cookies provided in a request. I wanted to add a new Filter that takes request parameters and returns them from request.getCookies() but only for a small number of URL patterns which we handle only internally, both for security (?) and also for performance, since this isn't a really common thing for us to do. So I have these two filters: cookieUserFilter ... cookieParameterFilter ... cookieParameterFilter *.xml.do /some/specific/pattern cookieUserFilter *.do *.jsp I have tested that both Filters work as expected when called. However, when I configure them as above and request /foo.xml.do, only the cookieUserFilter is being called. The cookieParameterFilter is not being called. I'm explicitly defining them in that order to ensure that the cookieParameterFilter is called /first/ to ensure that the parameters are converted into Cookies before the cookieUserFilter is called. In order to get the cookieParameterFilter to be called, I have to configure it like this in my filter-mapping: cookieParameterFilter *.do *.xml.do /some/specific/pattern This means it will apply to all requests, which isn't what I want. The only thing I can think of is that *.xml.do isn't mapped to any specific servlet, while *.do /is/. Will s only apply to URL patterns that are explicitly-mapped to a specific servlet? That doesn't sound right to me. I have other mappings that only map to a URL space and not anything that has a specific servlet mapping. What am I missing? This is Tomcat 9.0.85 and everything is defined in WEB-INF/web.xml. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 9.0.88 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.88. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.88 is a bugfix and feature release. The notable changes compared to 9.0.87 include: - Cookies header generation enhancements. - Fix regression when reloading TLS configuration and files. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 11.0.0-M19 (alpha) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 11.0.0-M19 (alpha). Apache Tomcat 11 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. A migration tool is available to aid this process. Apache Tomcat 11.0.0-M19 is a milestone release of the 11.0.x branch and has been made to provide users with early access to the new features in Apache Tomcat 11.0.x so that they may provide feedback. The notable changes compared to 11.0.0-M18 include: - Finalize update to the Jakarta EE 11 specifications. - Cookies header generation enhancements. - Fix regression when reloading TLS configuration and files. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-11.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-11.cgi Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat log warnings for connection parameter limits?
It would be worth creating an enhancement request for this in Bugzilla to ensure the request doesn't get forgotten about. Mark On 16/04/2024 01:06, Baron Fujimoto wrote: From our perspective, it needn't be super timely. It would be more for forensic confirmation that there's something we should consider. I think a hysteresis behavior would be compatible with this. On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas wrote: On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be something that would be left on in a live> system. We can set these parameters, so it would be useful to know if we were hitting the set limits. For the connection limit: How timely do you need the information to be? It is much easier to add a check when the connection is closed since a) it returns the current count and b) we are already checking the return value for mis-counting. For the thread limit: We have a couple of options here. (We use a custom queue which effectively changes the way threads in the pool re used.) The simplest is probably to add log in TaskQueue.offer() if all threads are currently being used. I'm not sure I fully grasp how this additional logging presents a significant incremental DOS risk. I mean, if an attacker is flooding you with enough traffic or connections where this becomes an issue, aren't you already logging various aspects of the attempts anyway (e.g., access logs, etc)? At that point aren't your logs already being filled anyway? It is an area we need to be careful with. Log messages that include exceptions are of greatest concern since they are relatively expensive to generate. If an invalid HTTP message triggers a log message with an exception (it does, but only when configured for debug logging) then there is a degree of DoS risk there. Access logs are a special case and one that we have taken care to try and optimise. Still, if you want to make a performance test look good turning off access logging is one of the first things to do (and of course results in totally meaningless results that don't reflect real world usage). I think the concern Chris was trying to express (although I'm sure he'll correct me if I am wrong) is that when these limits are reached there is a risk of a lot of log messages being generated and that can cause issues both from a performance issue and from just filling the logs with the same message over and over again. I think what we would need is some form of hysteresis. Log a message when the limit is reached, log another message when usage falls below 80%? of the limit. That way, administrators see the peaks in usage but aren't inundated with log messages. My only concern is that at least some this code is going to run for every single request. It needs to be efficient. We should measure the impact of adding this code before we decide on whether to include it. Mark On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz < ch...@christopherschultz.net> wrote: Baron, On 4/9/24 16:33, Baron Fujimoto wrote: I'm investigating occasional 503 errors for our CAS service running in a Tomcat 10.1.x container. The 503s appear to correlate with some traffic spikes at the same time. The connector is configured as follows: Can Tomcat log info such as when the maxThreads or maxConnections limits are reached? I'm basically trying to see if there is a good way to more definitively determine what may have caused the 503s and what may be feasible to mitigate them. Are you thinking of a debugging feature or something to be left-on for a live production system? Such logging might be considered a DOS vector for a live system: you can fill the logs by asking lots of trivial requests. -chris - 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
