You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Tuomas Kiviaho (JIRA)" <ji...@apache.org> on 2006/05/13 09:16:09 UTC
[jira] Created: (PLUTO-240) Declared charset ignored when setting
render response content type
Declared charset ignored when setting render response content type
------------------------------------------------------------------
Key: PLUTO-240
URL: http://issues.apache.org/jira/browse/PLUTO-240
Project: Pluto
Type: Bug
Reporter: Tuomas Kiviaho
Here's a snippet from RenderResponseImpl
public void setContentType(String contentType)
throws IllegalArgumentException {
ArgumentUtility.validateNotNull("contentType", contentType);
String mimeType = StringUtils.getMimeTypeWithoutEncoding(contentType);
if (!isValidContentType(mimeType)) {
throw new IllegalArgumentException("Specified content type '"
+ mimeType + "' is not supported.");
}
getHttpServletResponse().setContentType(mimeType);
this.currentContentType = mimeType;
}
When mime is used as content type, the optional charset part of contentType is ignored. Should there be raised an java.lang.IllegalArgumentException if charset is appended or should the render response characterset part be fed with the contentType charset part.
The API is not too clear what to do here, but using JSP directive...
<jsp:directive.page contentType="image/svg+xml;charset=UTF-8" />
.. and receiving default encoding in response header without a warning is quite error prone.
The 1:1 functionality with HttpServletResponse is the working solution, since at least Apache Jasper seems to use setContentType instead of setCharacterEncoding.
I don't know if the Render response MIME is allowed to include charset, but at least RenderResponseImpl#getContentType had a comment saying:
// NOTE: in servlet 2.4 we could simply use this:
// return super.getHttpServletResponse().getContentType();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (PLUTO-240) Declared charset ignored when setting
render response content type
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-240?page=all ]
David DeWolf updated PLUTO-240:
-------------------------------
Affects Version/s: 1.2.0
Priority: Minor (was: Major)
> Declared charset ignored when setting render response content type
> ------------------------------------------------------------------
>
> Key: PLUTO-240
> URL: http://issues.apache.org/jira/browse/PLUTO-240
> Project: Pluto
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Tuomas Kiviaho
> Priority: Minor
>
> Here's a snippet from RenderResponseImpl
> public void setContentType(String contentType)
> throws IllegalArgumentException {
> ArgumentUtility.validateNotNull("contentType", contentType);
> String mimeType = StringUtils.getMimeTypeWithoutEncoding(contentType);
> if (!isValidContentType(mimeType)) {
> throw new IllegalArgumentException("Specified content type '"
> + mimeType + "' is not supported.");
> }
> getHttpServletResponse().setContentType(mimeType);
> this.currentContentType = mimeType;
> }
> When mime is used as content type, the optional charset part of contentType is ignored. Should there be raised an java.lang.IllegalArgumentException if charset is appended or should the render response characterset part be fed with the contentType charset part.
> The API is not too clear what to do here, but using JSP directive...
> <jsp:directive.page contentType="image/svg+xml;charset=UTF-8" />
> .. and receiving default encoding in response header without a warning is quite error prone.
> The 1:1 functionality with HttpServletResponse is the working solution, since at least Apache Jasper seems to use setContentType instead of setCharacterEncoding.
> I don't know if the Render response MIME is allowed to include charset, but at least RenderResponseImpl#getContentType had a comment saying:
> // NOTE: in servlet 2.4 we could simply use this:
> // return super.getHttpServletResponse().getContentType();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PLUTO-240) Declared charset ignored when setting
render response content type
Posted by "Tuomas Kiviaho (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-240?page=comments#action_12402213 ]
Tuomas Kiviaho commented on PLUTO-240:
--------------------------------------
The javadoc section <http://portals.apache.org/pluto/multiproject/portlet-api/apidocs/javax/portlet/RenderResponse.html#setContentType(java.lang.String)> states nothing about handling the incoming charset part, but the spec clearly states that "The portlet container should ignore any character encoding specified as part of the content type.", so following 1:1 the servlet spec is out of the question.
Making setLocale and setContentType not to have an impact on http result Content-Type could make the implementation more robust, since
<jsp:directive.page contentType="image/svg+xml;charset=UTF-8" />
<jsp:directive.page contentType="image/svg+xml" pageEncoding="UTF-8" />
while being semantically identical could generate different Content-Type http header. (Althoug Tomcat seems not to suffer from this and portal driver request inclusion ignores these settings.)
Note: The servlet 2.4 getContentType comment in original post when used as-is would make charset appearing as part of resulting MIME if it is set via HttpServletResponseWrappers setCharacterEncoding or setLocale if they are not modified.
This significantly lowers the bug report severity, but I don't seem to have privileges to modify the issue after creating it.
> Declared charset ignored when setting render response content type
> ------------------------------------------------------------------
>
> Key: PLUTO-240
> URL: http://issues.apache.org/jira/browse/PLUTO-240
> Project: Pluto
> Type: Bug
> Reporter: Tuomas Kiviaho
>
> Here's a snippet from RenderResponseImpl
> public void setContentType(String contentType)
> throws IllegalArgumentException {
> ArgumentUtility.validateNotNull("contentType", contentType);
> String mimeType = StringUtils.getMimeTypeWithoutEncoding(contentType);
> if (!isValidContentType(mimeType)) {
> throw new IllegalArgumentException("Specified content type '"
> + mimeType + "' is not supported.");
> }
> getHttpServletResponse().setContentType(mimeType);
> this.currentContentType = mimeType;
> }
> When mime is used as content type, the optional charset part of contentType is ignored. Should there be raised an java.lang.IllegalArgumentException if charset is appended or should the render response characterset part be fed with the contentType charset part.
> The API is not too clear what to do here, but using JSP directive...
> <jsp:directive.page contentType="image/svg+xml;charset=UTF-8" />
> .. and receiving default encoding in response header without a warning is quite error prone.
> The 1:1 functionality with HttpServletResponse is the working solution, since at least Apache Jasper seems to use setContentType instead of setCharacterEncoding.
> I don't know if the Render response MIME is allowed to include charset, but at least RenderResponseImpl#getContentType had a comment saying:
> // NOTE: in servlet 2.4 we could simply use this:
> // return super.getHttpServletResponse().getContentType();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (PLUTO-240) Declared charset ignored when setting
render response content type
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-240?page=all ]
David DeWolf updated PLUTO-240:
-------------------------------
Fix Version/s: 1.2.0
Affects Version/s: 1.1.0-beta2
(was: 1.2.0)
> Declared charset ignored when setting render response content type
> ------------------------------------------------------------------
>
> Key: PLUTO-240
> URL: http://issues.apache.org/jira/browse/PLUTO-240
> Project: Pluto
> Issue Type: Bug
> Affects Versions: 1.1.0-beta2
> Reporter: Tuomas Kiviaho
> Priority: Minor
> Fix For: 1.2.0
>
>
> Here's a snippet from RenderResponseImpl
> public void setContentType(String contentType)
> throws IllegalArgumentException {
> ArgumentUtility.validateNotNull("contentType", contentType);
> String mimeType = StringUtils.getMimeTypeWithoutEncoding(contentType);
> if (!isValidContentType(mimeType)) {
> throw new IllegalArgumentException("Specified content type '"
> + mimeType + "' is not supported.");
> }
> getHttpServletResponse().setContentType(mimeType);
> this.currentContentType = mimeType;
> }
> When mime is used as content type, the optional charset part of contentType is ignored. Should there be raised an java.lang.IllegalArgumentException if charset is appended or should the render response characterset part be fed with the contentType charset part.
> The API is not too clear what to do here, but using JSP directive...
> <jsp:directive.page contentType="image/svg+xml;charset=UTF-8" />
> .. and receiving default encoding in response header without a warning is quite error prone.
> The 1:1 functionality with HttpServletResponse is the working solution, since at least Apache Jasper seems to use setContentType instead of setCharacterEncoding.
> I don't know if the Render response MIME is allowed to include charset, but at least RenderResponseImpl#getContentType had a comment saying:
> // NOTE: in servlet 2.4 we could simply use this:
> // return super.getHttpServletResponse().getContentType();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira