Julian Sedding created SLING-7813:
-------------------------------------
Summary: SlingHttpServletResponseImpl should log when setStatus is
called after it is committed
Key: SLING-7813
URL: https://issues.apache.org/jira/browse/SLING-7813
Project: Sling
Issue Type: Improvement
Components: Engine
Affects Versions: Engine 2.6.12
Reporter: Julian Sedding
Assignee: Julian Sedding
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]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
