Joerg Hoh created SLING-13322:
---------------------------------
Summary: header-modifying calls should warn on include
Key: SLING-13322
URL: https://issues.apache.org/jira/browse/SLING-13322
Project: Sling
Issue Type: Task
Components: Engine
Reporter: Joerg Hoh
(a followup of SLING-12958)
According to the [servlet api
specification|https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#the-include-method],
the include servlet:
{quote}
cannot set headers or call any method that affects the headers of the
response[...]Any attempt to set the headers must be ignored
{quote}
This means that methods like sendError() and sendRedirect() are not allowed to
be used during an include. Those methods change the status and commit the
response, which both are headers being changed. As well as resetting the
response, which changes headers like content type back to null.
For this reason the methods affecting headers must be ignore the call. Today
this is already case like this:
{noformat:title=SlingJakartaHttpServletResponseImpl}
@Override
public void setContentLength(final int len) {
if (!this.isProtectHeadersOnInclude()) {
super.setContentLength(len);
}
}
{noformat}
which is the spec-compliant way to do this (Tomcat handles it the same way:
https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/Response.java#L1198).
But right now {{IsProtectHeadersOnInclude()}} is not active by default because
we assume that many applications rely on the old non-compliant behavior.
In order to ease the migration to have this feature turned on, we should always
warn, if code is relying on the old (non-spec compliant) behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
