Re: [undertow-dev] response-code handler bypasses configured error pages

Hmm, this is because the servlet status code is only triggered by a sendError method, not by just setting the code. You probably need to write a custom one that looks like this (plus the relevant predicate languge bits): public class SendErrorHandler implements HttpHandler { private final int code; public SendErrorHandler(int code) { this.code = code; } @Override public void handleRequest(HttpServerExchange exchange) throws Exception { ServletRequestContext src = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); ((HttpServletResponse)src.getServletResponse()).sendError(code); } } Stuart On Fri, 3 Jul 2020 at 09:40, Brad Wood <bdw429s(a)gmail.com&gt; wrote: > Thanks for the reply Stuart. I've tried this with no success, but > perhaps I'm doing it wrong. > > List<PredicatedHandler> ph = > PredicatedHandlersParser.parse(predicatesLines, _classLoader); > servletBuilder.addOuterHandlerChainWrapper(next -> > Handlers.predicates(ph,next)); > > When the response-code handler fires, I still get no response body. > > On a related note, when I move the predicates into an outer handler chain > wrapper, my default response listener also doesn't fire at all. > > On an unrelated train of thought, I've been trying to see if I can get > the default response listener to automatically dispatch the correct error > page, but that hasn't been going well either. If I don't use the outer > handler chain idea, but try to capture the empty response in a default > response listener, I can return a static message using the Sender class > > Sender sender = exchange.getResponseSender(); > sender.send(errorHTMLString); > > But if I try to run something this in my default response listener to > invoke my error pages > > ServletRequestContext src = > exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); > HttpServletResponseImpl response = src.getOriginalResponse(); > response.doErrorDispatch( exchange.getStatusCode(), > exchange.getReasonPhrase() ); > > Then it's as though nothing happens and I still get an empty response. > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad(a)coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Thu, Jul 2, 2020 at 6:17 PM Stuart Douglas <sdouglas(a)redhat.com&gt; > wrote: > >> The predicate languages are executed before the Servler handlers, so >> they won't be handled by Servlet error pages. >> >> If you are setting this all up programmatically you could use >> io.undertow.servlet.api.DeploymentInfo#addOuterHandlerChainWrapper to setup >> the predicate handler after the initial servlet one, which should mean that >> the servlet error handling will handle the response code. >> >> Stuart >> >> On Fri, 3 Jul 2020 at 08:25, Brad Wood <bdw429s(a)gmail.com&gt; wrote: >> >>> When I configure an error page similar to this: >>> >>> servletBuilder.addErrorPage( new ErrorPage( "404.html", 404)); >>> >>> This works great when I hit a path in my browser that doesn't exist. >>> The contents of the *404.html* file is served with a response code of >>> *404*. >>> >>> However, if I also use the predicate language to define something like: >>> >>> path(/box.json)->response-code(404) >>> >>> and then I hit *localhost/box.json* in my browser, I get a *404* >>> status code but with no response body. >>> >>> - The docs say the response-code handler ends the exchange, but >>> should it still respect the error pages? >>> - How can I modify my use of Undertow to respect the error pages >>> when using the response-code handler? >>> - I've seen in the docs the ability to have a >>> *addDefaultResponseListener()* but I'm not sure if it is the >>> correct solution for this, nor how I would access the error page >>> configuration dynamically as to not need to duplicate my work. >>> >>> Thanks! >>> >>> ~Brad >>> >>> *Developer Advocate* >>> *Ortus Solutions, Corp * >>> >>> E-mail: brad(a)coldbox.org >>> ColdBox Platform: http://www.coldbox.org >>> Blog: http://www.codersrevolution.com >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> >>