In Tomcat (and other web application servers) there is a way to set the size of the output buffer (when writing out the response) such that after a certain size it will automatically start flushing the data to the client and “commit” the response. This issue is caused when a JSP is almost to the buffer limit (default 8192) and then enabling browser monitoring with
Under normal circumstances this is totally fine on its own and would just work without anyone noticing but in the case of important pages (such as authentication pages, healthcheck endpoints, and others) it did not perform as anticipated, surfacing an exception and returning a 200 response. This is actually the expected behavior given the default configuration of the Tomcat application server.
The components responsible for this behavior are:
- The main class responsible for creating the JspWriter object which writes the actions and template data in a JSP page:
protected JspWriter(int bufferSize, boolean autoFlush)
It takes the following two parameters:
bufferSize - JspWriter (JSP 2.3 API Documentation - Apache Tomcat 8.0.53). The size of the buffer to be used by the JspWriter. Defaults to 8kb in the versions of Tomcat that I’ve tested so far.
autoFlush - JspWriter (JSP 2.3 API Documentation - Apache Tomcat 8.0.53). Whether the JspWriter should be autoflushing. Defaults to true.
Here is a breakdown of the parameters: Apache Tomcat JspWriter docs
JspWriter object is associated with the
PrintWriter object of the
ServletResponse in a way that depends on whether the page is or is not buffered. If the page is not buffered, output written to this
JspWriter object will be written through to the
PrintWriter directly, which will be created if necessary by invoking the
getWriter() method on the response object. But if the page is buffered, the
PrintWriter object will not be created until the buffer is flushed and operations like
setContentType() are legal. Since this flexibility simplifies programming substantially, buffering is the default for JSP pages.
Buffering raises the issue of what to do when the buffer is exceeded. Two approaches can be taken:
- Exceeding the buffer is not a fatal error; when the buffer is exceeded, just flush the output.
- Exceeding the buffer is a fatal error; when the buffer is exceeded, raise an exception.
Both approaches are valid, and thus both are supported in the JSP technology. The behavior of a page is controlled by the
autoFlush attribute, which defaults to
true. In general, JSP pages that need to be sure that correct and complete data has been sent to their client may want to set
false, with a typical case being that where the client is an application itself. On the other hand, JSP pages that send data that is meaningful even when partially constructed may want to set
true; such as when the data is sent for immediate display through a browser. Each application will need to consider their specific needs.
An alternative considered was to make the buffer size unbounded; but, this had the disadvantage that runaway computations would consume an unbounded amount of resources.
The “out” implicit variable of a JSP implementation class is of this type. If the page directive selects
autoflush="true" then all the I/O operations on this class shall automatically flush the contents of the buffer if an overflow condition would result if the current operation were performed without a flush. If
autoflush="false" then all the I/O operations on this class shall throw an IOException if performing the current operation would result in a buffer overflow condition.
With best practices in mind, there are a few options available for mitigating this issue going forward:
- Disable browser auto-instrumentation while leaving APM enabled
- Increase the JSP output buffer size
- Disable automatic browser monitoring only for the JSP that ran into this issue and opt for manual instrumentation instead (This step would allow for browser auto-instrumentation still, but disable it for those specific pages (login, auth, healthchecks, heavier loaded JSPs). You would need to opt for manual JSP instrumentation if you needed monitoring for those specific webpages above)