[
https://issues.apache.org/jira/browse/SLING-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415128#comment-17415128
]
Julian Sedding commented on SLING-7813:
---------------------------------------
[~bdelacretaz] just for the record. The commit you linked does not change the
behaviour. After the logging {{#setStatus()}} always delegates back to
{{super}} (maybe you didn't notice the end of the if-statement checking for
{{isCommitted()}}?). It could be argued that delegating
{{#setStatus(statusCode, null)}} to {{#setStatus(statusCode)}} is a behavioural
change, but that should be very subtle and we could improve this if desired.
> 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
> Priority: Minor
> Fix For: Engine 2.6.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
