[
https://issues.apache.org/jira/browse/MYFACES-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891175#action_12891175
]
Werner Punz commented on MYFACES-2835:
--------------------------------------
Hi since I am sitll on vacation until the end of the week just a short
response. I did a fixup for the Partial Response Writer for nested CDATA
blocks. Because there fixing it was valid because we enforce the html data to
be rendered into a CDATA and nested CDATA blocks must be properly fixed so that
a valid decoding of it results in a final CDATA on the browsers side.
The fixup simply was to split a ]]> into something like
]]><![CDATA[]]]]><![CDATA[>
Now this looks weird but makes sense, because the xml spec clearly says that in
a cdata block every sequence of characters is allowed to occur unless it is a
]]> which marks the end. The solution is to split the sequence ]]> into
separate cdata blocks so that we have multiple cdatas which if decoded result
in a valid ]]>
I implemented this solution in the partial response writer via double
buffering. If a cdata block was opened then the strings being pushed into the
response writer were buffered and once the end of cdata within the proper depth
was reached the string was cdata escaped before being given to the final
underyling response writer.
I also tested against mojarra which had similar fixes in as it seems, but it
failed in one of my testcases where a cdata block was embedded somewhere in
another cdata block in a javascript alert box.
But I also said that the error clearly also is on primefaces side here, because
they issue nested cdata blocks and rely on the impls standard response writer
to resolve that clearly. Now fixing this on the response writers side is
perfectly viable if we have an xmlis response format, but what if we have a an
output format where nested CDATA blocks are perfectly legal?
Ok this is hypothetical, but the way the response writer is designed it does
not prevent false inputs it follows the rule garbage in -> garbage out.
Just to say my 2c, but I have promised to discuss that next week on the open
list (due to my vacation I cannot do it this week properly), if someone wants
to bring it earlier to jsf open, feel free :-)
But as I said this is only valid because our partial lifecycle enforces an xml
and enforces that every html string has to be embedded in a cdata block
outside, hence naturally nested cdata blocks can occur.
> ResponseWriter.startCDATA() and endCDATA() methods should take no action
> according to the Javadocs
> --------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2835
> URL: https://issues.apache.org/jira/browse/MYFACES-2835
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-252
> Affects Versions: 2.0.1
> Reporter: Bruno Aranda
> Assignee: Bruno Aranda
> Fix For: 2.0.2-SNAPSHOT
>
>
> Hence, the body of this methods should be empty.
> This is highlighted by a problem with Primefaces, where Mojarra works without
> problems and Myfaces not, because it adds nested CDATA sections, hence
> breaking the custom partial response XML created by Primefaces.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
