Details
-
Bug
-
Resolution: Done
-
Major
-
7.2.0.GA
-
None
Description
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?
Attachments
Issue Links
- incorporates
-
-
- Resolved
-
- is incorporated by
-
JBEAP-16775 [GSS](7.2.z) Upgrade Undertow from 2.0.20 to 2.0.22
-
- Verified
-
