[
https://issues.apache.org/jira/browse/MYFACES-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887388#action_12887388
]
Werner Punz edited comment on MYFACES-2811 at 7/12/10 10:54 AM:
----------------------------------------------------------------
Ok got it, primefaces uses its own partial lifecycle mechanism a request from
primefaces looks like following:
j_id914123403_367c6b00_su... j_id914123403_367c6b00_submit
javax.faces.ViewState
KLbUCI2NVQHOAk/gg+lUKpzTubwEZ68OjNf/sSooRLAZEtdiHul6VRAS+OV+DCswXv1dgNQqUZxb
mEHspI+kokh0MhBghr+nLHMTTKKA7/ldudnPxOlwnP7PqKNrlYGrEr+2iw==
primefacesPartialRequest true
primefacesPartialUpdate testForm
testForm_SUBMIT 1
Which is not!!! a jsf 2 ppr request, he then renders his own response protocol
by leveraging the standard html response writer
<?xml version="1.0"
encoding="UTF-8"?><partialResponse><components><component><id>testForm</id>....
which is a primefaces only protocol and there our CDATA fixes did not kick in
because they were only implemented on top of the html responsewriterImpl
I have to admit our impl is partially at fault here, because startCDATA is a
valid jsf2 command on ResponseWriter level, and I only fixed the issue on
ResponseWriterImpl level. We probably have to introduce the regexp fixup on
responseWriter level as well. As it seems Mojarra has done the same mistake we
did by fixing it only in PPRResponseWriter level.
On the other hand the spec does not enforce the escaping of nested CDATA the
spec says
>Open an XML CDATA block. Note that XML does not allow nested CDATA blocks,
>though this method does not enforce >that constraint. The default
>implementation of this method takes no action when invoked.
So I am not sure if we have to fix it really, especially since primefaces
bypasses the partialResponse by rolling its own mechanism and mojarra also does
not do the check for speed reasons.
was (Author: werpu):
Ok got it, primefaces uses its own partial lifecycle mechanism a request
from primefaces looks like following:
j_id914123403_367c6b00_su... j_id914123403_367c6b00_submit
javax.faces.ViewState
KLbUCI2NVQHOAk/gg+lUKpzTubwEZ68OjNf/sSooRLAZEtdiHul6VRAS+OV+DCswXv1dgNQqUZxb
mEHspI+kokh0MhBghr+nLHMTTKKA7/ldudnPxOlwnP7PqKNrlYGrEr+2iw==
primefacesPartialRequest true
primefacesPartialUpdate testForm
testForm_SUBMIT 1
Which is not!!! a jsf 2 ppr request, he then renders his own response protocol
by leveraging the standard html response writer
<?xml version="1.0"
encoding="UTF-8"?><partialResponse><components><component><id>testForm</id>....
which is a primefaces only protocol and there our CDATA fixes did not kick in
because they were only implemented on top of the html responsewriterImpl
I have to admit our impl is partially at fault here, because startCDATA is a
valid jsf2 command on ResponseWriter level, and I only fixed the issue on
ResponseWriterImpl level. We probably have to introduce the regexp fixup on
responseWriter level as well. As it seems Mojarra has done the same mistake we
did by fixing it only in PPRResponseWriter level.
> Partial Response still embedded CDATA possible
> ----------------------------------------------
>
> Key: MYFACES-2811
> URL: https://issues.apache.org/jira/browse/MYFACES-2811
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.1-SNAPSHOT
> Reporter: Werner Punz
>
> We worked on this issue a while ago yet I got another error report in - Bruno
> Aranda is reporting:
> Hi,
> I have a partial response that contains invalid syntax because CDATA
> sections are nested. For example, in my app this code is generated in
> the partial response:
> <?xml version="1.0"
> encoding="UTF-8"?><partialResponse><components><component><id>editorForm</id><output><![CDATA[<form
> id="editorForm" name="editorForm" method="post"
> action="/editor/curate/publication.jsf?conversationContext=2"
> enctype="application/x-www-form-urlencoded"><span
> id="growl"></span><script type="text/javascript">//<![CDATA[
> jQuery.gritter.add({title:'Publication saved',text:'AC:
> EBI-2637354',image:'/editor/primefaces_resource/2.0.3-SNAPSHOT/primefaces/growl/assets/info.png?conversationContext=2',sticky:false});
> //]]></script>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
