Headers added to PortletResponse are not set in response after LPS-56346

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.2.X EE
• Fix Version/s: 6.2.X EE, 7.0.X EE, 7.0.0 DXP FP33, 7.0.0 DXP SP7, 7.0.5 CE GA6, Master
• Component/s: Core Infrastructure
• Labels:
  • QA-F
  • ee-6.2.x-only
  • ee-ts
  • liferay-digital-enterprise-70-sp7
  • liferay-fixpack-de-33-7010
  • liferay-fixpack-portal-164-6210
• Branch Version/s:
  7.0.x, 6.2.x
• Backported to Branch:
  Committed
• Story Points: 1.5
• Fix Priority: 4
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/52543
• Bug Type: Regression Bug
• What problem did the customer find?:
  Hide

  The [LPSs listed here|https://issues.liferay.com/browse/LPS-62085?focusedCommentId=1049483&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1049483] doesn't solve the issue, as MetaInfoCacheServletResponse#finishResponse() that should set the headers is never called. (Verified on ee-6.2.x.)

  Show

  The [LPSs listed here| https://issues.liferay.com/browse/LPS-62085?focusedCommentId=1049483&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1049483 ] doesn't solve the issue, as MetaInfoCacheServletResponse#finishResponse() that should set the headers is never called. (Verified on ee-6.2.x.)
• What do you think is the root cause? (if known): MetaInfoCacheServletResponse#finishResponse() is still not called.

Technical Background:
Servlet specification states that header modification attempts should be ignored in case of include dispatch. Therefore calling HttpServletResponse#setHeader(String, String) is useless in portlets, PortletResponse#setProperty() can be used instead. The headers will be transferred later from PortletResponse to HttpServletResponse.

jsf-download-WRONG-portlet.war shows the wrong approach while jsf-download-portlet.war the proper one. These portlets sets "Content-Type" and "Content-Disposition" headers to demonstrate file download scenario. The expected result to download "test.txt" works only with the latter.

Issue:
Cookies are not set even if using PortletResponse#setProperty().

Steps to reproduce:
1- Deploy the attached cookietest-portlet-6.2.10.1.war, it contains the following snippet, in its doView method:

Cookie testNameCookie = new Cookie("TEST_COOKIE_NAME",  URLEncoder.encode("my-test-cookie", "UTF-8"));
                 strollerNameCookie.setVersion(0);
                 strollerNameCookie.setPath("/");
                 strollerNameCookie.setMaxAge(-1);
                 renderResponse.addProperty(testNameCookie);

2- Log in, and place the cookie test portlet on the page
3- Hit the Click Me button and verify that

The cookie is set (check the server's console or refresh the page and check the "Cookies" in the browser's dev toolbar)
4- Log out and clear the cookies or open a private browser session & access the portal:
Result: The cookie is not set, despite the portlet's doView method is executed.