Regarding ExternalContext.getResponseContentType(), Section 220.127.116.11 of the JSR 329 Spec (titled "Methods that deviate from Faces 1.2 Javadoc") states:
Return the MIME Content-Type for this response. If called during the RENDER_PHASE or RESOURCE_PHASE, returns the value from the corresponding render response.getContentType()[6.62, 6.129]. If called during the ACTION_PHASE or EVENT_PHASE it throws an IllegalStateException[6.63, 6.130].
However, the tck-tests.md file contains the following test description, which describes a requirement for the bridge implementation (not the bridge's implementation of ExternalContext):
[5.29] If RenderResponse.getContentType() returns null and there is no other indication of desired content type (not defined by this specification; i.e. an implementation specific extension) then the bridge must call RenderResponse.setContentType() passing the value returned from RenderRequest.getResponseContentType()
There are two problems worth noting:
1. The Apache MyFaces Portlet Bridge (the Reference Implementation for JSR 329) does not have any Java code that calls the RenderResponse.setContentType(String) method.
2. The test for 5.29 does not check RenderResponse.getContentType() to see if it returns null (as described in the tck-tests.md file).
If both of these problems exist, then why does Apache Pluto 2.0.x pass JSR 329 TestPage058 (bridgeSetsContentTypeTest)?
One reason why it passes is because the test relies on SingleRequestTest.jsp, which contains the following line:
This has the effect of generating java source code from the JSP that looks like the following:
Another reason it passes is because Apache Pluto 2.0.x source contains the following implementation for RenderResponse.setContentType(String) which will remove ";charset=UTF-8" from the specified contentType:
This issue serves as a proposal for:
1. Adding a requirement to Section 18.104.22.168 so that ExternalContext.getResponseContentType() returns the value of HeaderRequest.getContentType() if the return value of HeaderResponse.getContentType() is null. (Note that due to
FACES-2696, the JSR 378 FacesBridge runs the JSF lifecycle in the `HEADER_PHASE` instead of the `RENDER_PHASE`).
2. Refactoring Test 5.29 to utilize a portlet-filter that decorates the `HeaderResponse`, ensuring that `HeaderResponse.getContentType()` returns null.
3. Edit the tck-tests.md file such that Test 5.29 reflects the new requirement, and remove the requirement for `RenderResponse.setContentType()` to be called.