[
https://issues.apache.org/jira/browse/SLING-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh resolved SLING-13322.
-------------------------------
Fix Version/s: Engine 3.0.4
Resolution: Fixed
> 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
> Assignee: Joerg Hoh
> Priority: Major
> Fix For: Engine 3.0.4
>
>
> (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]).
> The methods should not throw an exception (as SLING-12958 requested).
> 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.
> For the {{setContentType}} method this is already present, so this should
> remain unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
