You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/11/11 13:40:44 UTC
[jira] Created: (SLING-726) Prevent
ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
----------------------------------------------------------------------------
Key: SLING-726
URL: https://issues.apache.org/jira/browse/SLING-726
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.0.2
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Priority: Critical
Fix For: Engine 2.0.4
The Servlet API 2.4 specifies that calls to the ServletResponse.setCharacterEncoding() method should be ignored if the response has already been committed or if the getWriter() method has already been called. Likewise the character encoding being specified through ServletResponse.setContentType() should be ignored if the getWriter() method has already been called (setContentType should be ignored if the response has already been committed).
Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead chooses to act upon it. It looks like WebLogic internally recodes, what has already been written, and resets it into the output buffer, but does not seem to reset the buffer offset before doing this. This causes all kind of garbage of previous requests (since buffers seem to be reused) to be added to the output ....
Sling should workaround this issue by overwriting the setCharacterEncoding and setContentType methods to prevent the character encoding from being changed after getWriter() has been called.
The reason, why Sling may run into problems is, that the DefaultSlingScript used by the scripting/core module to adapt scripts to the Servlet interface automatically sets the character encoding before calling the actual script. This may cause responses handled by Sling to become garbled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-726) Prevent
ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-726.
-----------------------------------
Resolution: Fixed
Implemented and tested this fix in Rev. 713028.
Specially handling the setContentType() method seems not to be required, since WebLogic 10.3 seems to correctly ignore the character set setting in this method call.
> Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
> ----------------------------------------------------------------------------
>
> Key: SLING-726
> URL: https://issues.apache.org/jira/browse/SLING-726
> Project: Sling
> Issue Type: Bug
> Components: Engine
> Affects Versions: Engine 2.0.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Priority: Critical
> Fix For: Engine 2.0.4
>
>
> The Servlet API 2.4 specifies that calls to the ServletResponse.setCharacterEncoding() method should be ignored if the response has already been committed or if the getWriter() method has already been called. Likewise the character encoding being specified through ServletResponse.setContentType() should be ignored if the getWriter() method has already been called (setContentType should be ignored if the response has already been committed).
> Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead chooses to act upon it. It looks like WebLogic internally recodes, what has already been written, and resets it into the output buffer, but does not seem to reset the buffer offset before doing this. This causes all kind of garbage of previous requests (since buffers seem to be reused) to be added to the output ....
> Sling should workaround this issue by overwriting the setCharacterEncoding and setContentType methods to prevent the character encoding from being changed after getWriter() has been called.
> The reason, why Sling may run into problems is, that the DefaultSlingScript used by the scripting/core module to adapt scripts to the Servlet interface automatically sets the character encoding before calling the actual script. This may cause responses handled by Sling to become garbled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-726) Prevent
ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646541#action_12646541 ]
Bertrand Delacretaz commented on SLING-726:
-------------------------------------------
I hate to have to implement workarounds for broken app servers, but agree that it is useful for Sling to be resilient again such problems.
I suggest identifying the corresponding code as a workaround in code comments, as that should normally be none of Sling's business.
> Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
> ----------------------------------------------------------------------------
>
> Key: SLING-726
> URL: https://issues.apache.org/jira/browse/SLING-726
> Project: Sling
> Issue Type: Bug
> Components: Engine
> Affects Versions: Engine 2.0.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Priority: Critical
> Fix For: Engine 2.0.4
>
>
> The Servlet API 2.4 specifies that calls to the ServletResponse.setCharacterEncoding() method should be ignored if the response has already been committed or if the getWriter() method has already been called. Likewise the character encoding being specified through ServletResponse.setContentType() should be ignored if the getWriter() method has already been called (setContentType should be ignored if the response has already been committed).
> Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead chooses to act upon it. It looks like WebLogic internally recodes, what has already been written, and resets it into the output buffer, but does not seem to reset the buffer offset before doing this. This causes all kind of garbage of previous requests (since buffers seem to be reused) to be added to the output ....
> Sling should workaround this issue by overwriting the setCharacterEncoding and setContentType methods to prevent the character encoding from being changed after getWriter() has been called.
> The reason, why Sling may run into problems is, that the DefaultSlingScript used by the scripting/core module to adapt scripts to the Servlet interface automatically sets the character encoding before calling the actual script. This may cause responses handled by Sling to become garbled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-726) Prevent
ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646545#action_12646545 ]
Felix Meschberger commented on SLING-726:
-----------------------------------------
@Bertrand
I agree with you whole heartedly.
Yet it took me almost two days, to find the cause for the problem of garbage in the output ! So implementing this workaround to ensure behaviour is spec-compliant (instead of being a buggy extension) is acceptable by me.
If have placed comments referring to this bug such that the complete discussion may be tracked.
> Prevent ServletResponse.setCharacterEncoding in SlingHttpServletResponseImpl
> ----------------------------------------------------------------------------
>
> Key: SLING-726
> URL: https://issues.apache.org/jira/browse/SLING-726
> Project: Sling
> Issue Type: Bug
> Components: Engine
> Affects Versions: Engine 2.0.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Priority: Critical
> Fix For: Engine 2.0.4
>
>
> The Servlet API 2.4 specifies that calls to the ServletResponse.setCharacterEncoding() method should be ignored if the response has already been committed or if the getWriter() method has already been called. Likewise the character encoding being specified through ServletResponse.setContentType() should be ignored if the getWriter() method has already been called (setContentType should be ignored if the response has already been committed).
> Unfortunately BEA WebLogic 10.3 seems to no ignore this call and instead chooses to act upon it. It looks like WebLogic internally recodes, what has already been written, and resets it into the output buffer, but does not seem to reset the buffer offset before doing this. This causes all kind of garbage of previous requests (since buffers seem to be reused) to be added to the output ....
> Sling should workaround this issue by overwriting the setCharacterEncoding and setContentType methods to prevent the character encoding from being changed after getWriter() has been called.
> The reason, why Sling may run into problems is, that the DefaultSlingScript used by the scripting/core module to adapt scripts to the Servlet interface automatically sets the character encoding before calling the actual script. This may cause responses handled by Sling to become garbled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.