Hi, A few weeks ago on jboss-as7-dev, Undertow compatibility with Tomcat valves and -D options was briefly mentioned. Direct compatibility is a different topic, but I think it is important to make sure that Undertow can cover the reasons people are using some of those Tomcat options. I've done some analysis on the JBoss support cases Red Hat deals with and our knowledge base, and had a bit of a look over the community forums. I looked at the forums less since it's less structured data but what people mention there seems consistent with the the RH support cases. I'm sorry this post is as long as it is, but hopefully what I've found will help make sure we think about some cases people may run into using Undertow, and remind us of a few lessons to learn from previous Tomcat/JBossWeb bugs. The most common valves we see people add are the RewriteValve, RequestDumperValve and AccessLogValve. UNDERTOW-12 and UNDERTOW-17 are already filed for equivalents to the first two. I can't see any code or open JIRA issues for access logging, which I imagine people will want. The most commonly used Tomcat -D option is org.apache.catalina.STRICT_SERVLET_COMPLIANCE=false. When it's discussed, it always seems to be added for the effect of not enforcing "any wrapped request or response object passed to an application dispatcher will be checked to ensure that it has wrapped the original request or response. (SRV.8.2 / SRV.14.2.5.1)". Undertow enforces that clause. A quick search for "ApplicationDispatcher.checkSameObjects" shows people running into this all over the place. Including https://issues.jboss.org/browse/RESTEASY-745 (which has a work-around). Unfortunately a reasonable number of libraries have had or still have bugs where their wrappers don't derive from the spec one, and it only break when someone tries to pass it to the dispatcher. There are a few uses of org.apache.tomcat.util.http.Parameters.MAX_COUNT, that adjusts the arbitrary limit on the parameter count which was added to prevent DoS attacks using hash collisions. Looking at the code, there appear to be several places where Undertow could suffer similar DoS attacks where client data is used as HashMap keys: CookieHandler, HttpServletRequestImpl.getParameterMap() and so on. Two important things here: what protection does/will Undertow have against those attacks (such as a limit on the number of parameters, and is there a way of changing the arbitrary limit. It's not the best idea to do that, but I've seen at least two people saying they have >2000 hidden parameters in some of their forms. There are a few options that get used a bit for session cookies. You can change the cookie name from JSESSIONID on a per-webapp basis, but Tomcat has a org.apache.catalina.JSESSIONID option to set it globally. This is probably more of a WildFly integration thing, but is there a plan to allow it to be changed globally? org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE is used occasionally to allow un-escaped equals signs in the cookie value. org.apache.tomcat.util.http.ServerCookie.VERSION_SWITCH=false is used occasionally to not switch v0 cookies to v1 cookies, to deal with some broken clients. See JBWEB-196. org.apache.catalina.connector.Response.REWRITE_CONTEXT_CHECK=false is used primarily in WebLogic migrations. See JBWEB-181, but apparently when encodeRedirectURL() adds the sessionId to the url, WL will do that for URLs belonging to other contexts. I'm not sure if this is still useful. By default Tomcat un-escapes %2F in a URL to / to prevent security flaws by something incorrectly doing it later. org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH can be used to disable that, for example if you want to put %2F inside a path component of a REST service. Should Undertow to the same automatic un-escaping, and if so have a way not to do it? The final option that I've seen used a non-trivial number of times is org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER. Jasper has re-sizable buffers which are pooled for performance but may need to grow arbitrarily large to render some JSPs. By default the enlarged buffers are kept in the pool like normal ones, which means a bad JSP render consuming hundreds of mb will not free the extra memory when it finishes. This option causes it to shrink the buffers back down after they're finished being used. The moral for Undertow here is if you have resizable buffers and they get pooled, make sure the is a limit. -- James "Doc" Livingston JBoss Support Engineering Group