[
https://issues.apache.org/jira/browse/SLING-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-13322:
------------------------------
Description:
(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.
was:
(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.
> 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
> Priority: Major
>
> (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)
