GFP.getResponseContentType breaks Portlet Spec PLT.12.3.1
---------------------------------------------------------
Key: PORTLETBRIDGE-62
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-62
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: API
Affects Versions: 1.0.0-beta
Reporter: Jondean Haley
method:
public String getResponseContentType(PortletRequest request)
{
String contentType =
getPortletConfig().getPortletContext().getInitParameter(DEFAULT_CONTENT_TYPE);
if (contentType == null)
{
contentType = request.getResponseContentType();
}
return contentType;
}
This method is used by GFP.setResponseContentType.
Problem, by PLT.12.3.1 - PortletResponse.setResponseContentType MUST set a
content type from the set returned from PortletRequest.getResponseContentTypes,
which is the set formed by the intersection of those types supported by the
portal AND the portlet, as defined in portlet.xml. The method above sets the
content type to an arbitrary init parm in preference to using the default type
as defined by both the portal and portlet (and further, the current mode). If
I set this init parm to "hello", I break the spec. If this init parm is set to
a value that the portal cannot support, the portal behavior is undefined, but
it can throw an exception on receipt of the HTTPS response with a content type
that is not part of its requested set.
Why was this init parm introduced? It appears unnecessary.
DEFAULT_CONTENT_TYPE does not appear in the Spec Ch.3 on init parms. The
portlet.xml handles default content type, as returned from
PortletRequest.getReponseContentType(), which, by spec, MUST be the first
content type returned from the set-returning getResponseContentTypes().
A 2nd issue: BridgeImpl.doFacesRequest sets the content-type again,
overwriting that of doDispatch in the GFP (which uses the above method). Code
of BridgeImpl.doFacesRequest:
if (extCtx.getResponseContentType() == null)
{
response.setContentType(extRequest.getResponseContentType());
}
It appears that this can and should be removed. This may be why use of
DEFAULT_CONTENT_TYPE has not been a problem so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
