No, in Undertow these are not created until the request has actually been delegated to a Servlet context (as it is possible for requests to not be using Servlet at all). What are you trying to do? There is probably a way to do it using native Undertow handlers. Stuart On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding(a)uwaterloo.ca&gt; wrote: > Hi, > > Is there a method or workaround that would allow the the initial level > Handler (e.g., PathHandler) for an undertow server access HttpServletRequest > and HttpServletResponse? I am trying to switch our server from Embedded > Jetty, in which the initial handler does some processing using the > HttpServletRequest and Response before matching and delegating to the > appropriate ServletContextHandler, however in Undertow it seems these are > not created (via ServletRequestContext) until after the matching. > > > Thank you, > > > Jack > > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev

Hello, not directly a answer to your question (doing it in handlers will work, it is just not very porable) but a comment (if I understood your plan correctly): Delaying (failed? flooded?) requests might look like a good thing to do for security but it only allows attackers to overflow your servers more easily. Quick closing of connections is a better idea - and in case of password attempts adding the IP dynamically to a (local) blacklist. Because even when you have a powerful async server like undertow the resource consumption of an open tcp socket is enormous (compared to an attacker with a stateless attack tool or ddos pool). Gruss Bernd Am Mon, 11 Jul 2016 10:50:10 -0400 schrieb Jack Ding <z29ding(a)uwaterloo.ca&gt;: > Hi Stuart, > > Thank you for your response. We have a filter class at the top level > currently which authenticates and tracks requests and may decide to > delay a request using AsyncContext's timeout. When implemented at the > top level before being delegated to a servlet, the > asynccontext.dispatch will cause the request (after the delay) to > come back through the same filter class. If it is done after being > delegated, the dispatch will directly access the resource requested. > The class will mostly work in the same way if added as an outer > handler to the servlet context, except that dispatch will directly go > to the underlying resource. > > Thanks, > Jack > > On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas(a)redhat.com&gt; > wrote: > > > No, in Undertow these are not created until the request has actually > > been delegated to a Servlet context (as it is possible for requests > > to not be using Servlet at all). > > > > What are you trying to do? There is probably a way to do it using > > native Undertow handlers. > > > > Stuart > > > > On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding(a)uwaterloo.ca&gt; > > wrote: > > > Hi, > > > > > > Is there a method or workaround that would allow the the initial > > > level Handler (e.g., PathHandler) for an undertow server access > > HttpServletRequest > > > and HttpServletResponse? I am trying to switch our server from > > > Embedded Jetty, in which the initial handler does some processing > > > using the HttpServletRequest and Response before matching and > > > delegating to the appropriate ServletContextHandler, however in > > > Undertow it seems these are not created (via > > > ServletRequestContext) until after the matching. > > > > > > > > > Thank you, > > > > > > > > > Jack > > > > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev