-
Bug
-
Resolution: Done
-
Major
-
7.2.0.GA
-
None
If a JSP include is nested in a custom tag, then a 500 response code is returned, but the response is otherwise good. This worked before on EAP 6/JBossWeb. For example:
<ex:repro><jsp:include page="/include.html"></jsp:include></ex:repro>
Undertow debug logging shows an IOException:
2019-04-16 15:49:57,155 DEBUG [io.undertow.request.io] (default task-1) UT005013: An IOException occurred: java.io.IOException
at io.undertow.servlet.core.BlockingWriterSenderImpl.writeBuffer(BlockingWriterSenderImpl.java:208)
at io.undertow.servlet.core.BlockingWriterSenderImpl.send(BlockingWriterSenderImpl.java:75)
at io.undertow.server.handlers.resource.PathResource$1ServerTask.run(PathResource.java:184)
at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:253)
at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:111)
at org.wildfly.extension.undertow.deployment.ServletResource.serve(ServletResource.java:96)
at io.undertow.server.handlers.resource.CachedResource.serve(CachedResource.java:168)
at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:357)
at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:198)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:219)
at io.undertow.servlet.spec.RequestDispatcherImpl.includeImpl(RequestDispatcherImpl.java:380)
at io.undertow.servlet.spec.RequestDispatcherImpl.setupIncludeImpl(RequestDispatcherImpl.java:315)
at io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:907)
BlockingWriterSenderImpl.writeBuffer calls writer.checkError(), which inherently flushes the BodyContent. But BodyContent.flush() always throws an exception so calling this always results in the trouble flag on the writer:
public void flush() throws IOException { throw new IOException("Illegal to flush within a custom tag"); }
Compared to JBossWeb, this would jsut write to the writer/BodyContent from DefaultServlet.copyRange and it would never call writer.checkError() or anything else to flush the BodyContent:
16:08:19,138 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.jasper.runtime.BodyContentImpl.write(BodyContentImpl.java:78) 16:08:19,138 INFO [stdout] (http-127.0.0.1:8080-3) java.io.PrintWriter.write(PrintWriter.java:426) 16:08:19,138 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:2166) 16:08:19,139 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1920) 16:08:19,139 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:843) 16:08:19,139 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:375) 16:08:19,139 INFO [stdout] (http-127.0.0.1:8080-3) javax.servlet.http.HttpServlet.service(HttpServlet.java:734) 16:08:19,139 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.servlets.DefaultServlet.service(DefaultServlet.java:356) 16:08:19,140 INFO [stdout] (http-127.0.0.1:8080-3) javax.servlet.http.HttpServlet.service(HttpServlet.java:847) 16:08:19,140 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) 16:08:19,140 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) 16:08:19,140 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832) 16:08:19,140 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:718) 16:08:19,141 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:655) 16:08:19,141 INFO [stdout] (http-127.0.0.1:8080-3) org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:890)
It seems that could miss actual issues so that is likely not an approach we should follow within Undertow. But can we avoid this 500 in Undertow in some manner?
- incorporates
-
-
- Resolved
-
- is incorporated by
-
JBEAP-16775 [GSS](7.2.z) Upgrade Undertow from 2.0.20 to 2.0.22
-
- Closed
-
