Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
Engine 2.6.12
-
None
Description
I have been debugging a scenario, where a response did not have the (in this case) expected status code 500 set by an error handling script, but instead the status code was 200.
It turns out that a rendering script calls #flushBuffer() on the response early on in order to optimize user experience. Later in the rendering chain a JSP causes a NullPointerException, triggering an error handler which calls #setStatus(500). The #setStatus call is silently ignored.
"Fixing" this problem would require buffering the entire response and ignoring any flush calls (be it #flushBuffer(), #getWriter().flush() or #getOutputStream().flush()). This would be a change in behaviour, a violation of the Servlet spec and performance issues waiting to happen. Thus I am ruling out this option.
However, it would be helpful to improve "debuggability" of the problem. I propose to log a warning when #setStatus() is called. Additionally, if debug logging is enabled, I propose to log a stack trace to identify where the flush call originated (unless the flush was due to too many bytes written, which is not very helpful information).
cc rombert
Attachments
Issue Links
- relates to
-
SLING-10810 new status code should not be set if response is already committed
- Closed
- links to