Bug 35284 – The libxml WebKit used may create multiple CDATA sections for original single CDATA section, which may break some web apps

• Component: XML
• Status: UNCONFIRMED

[Johnny(Jianning) Ding]

When putting the attached test.xml on your http server, than use WebKit based browsers like Safari or Chrome to visit it (for example http://localhost/test.xml?123 add parameter to avoid the cache), you will see the original single CDATA section will be parsed to two or three CDATA sections in those browsers. Typing javascript:alert(document.documentElement.childNodes.length) in address bar or using inspector to see the multiple CDATA sections the browsers got.

IE && FF do not have this issue.

Some web apps may be broken by this issue. For example, the Discuz!, the most popular forum platform in China, relies on the correct XML parsing to implement some features. in discuz\include\js\common.js, the function "ajaxpost" reads the CDATA section and puts the contents of CDATA section in the page. See the following code.

function ajaxpost(formid, showid, waitid, showidclass, submitbtn, recall) {
    ...
    var handleResult = function() {
        var s = '';
        ...
        try {
            if(BROWSER.ie) {
                s = $(ajaxframeid).contentWindow.document.XMLDocument.text;
            } else {
                s = $(ajaxframeid).contentWindow.document.documentElement.firstChild.nodeValue;
            }
        } catch(e) {
            ...
        }
        ...
    }
}

Bur now in WebKit, since libxml parsed out multiple CDATA sections instead of single CDATA section like the original data, only part of contents are added in page and the functionalities of the page are all broken. Almost millions of discuz! based sites are affected. I personally think we should fix this issue.

After digging in the libxml source code, I found the problem was because the parser of libxml created a small CDATA section (300 XMLChars, see the definition of XML_PARSER_BUG_BUFFER) when it entered into a valid CDATA section but wasn't able to find the valid end tag of CDATA section (which is "]]>"). (Please refer to libxml/parse.c, line: 10426, code: base = xmlParseLookupSequence(ctxt, ']', ']'. '>'); )

The contents' length of the single CDATA section in the test.xml is 65737(all US-ASCII characters). When debugging with Chromium,  the length of first part data the WebKit sent to libxml was 3852, so the libxml created and push a CDATA section 
which is 300 characters since it could NOT find the valid end tag of CDATA section. Until the last part data came, so the libxml parser found the the valid end tag "]]>", the rest contents of the original CDATA section are put into another CDATA 
section. At last we got multiple CDATA sections instead of single CDATA section like the original data. As long as the single CDATA section is too big to let libxml one-time access the whold CDATA section, the issue occurs.

I don't know why libxml has this logic to handle CDATA section, after removing the logic of creating a 300 characters when it entered into a valid CDATA section but wasn't able to find the valid end tag of CDATA section, the bug is gone.
I am not familiar with libxml, if any experts know the reason of the above logic (why use it and whether it can be changed), please help on fixing this issue. Otherwise, I gonna send a bug to xmlsoft for this issue.

Thanks!

[Johnny(Jianning) Ding]

Created attachment 49265 [details]
the test.xml file

[Mark Rowe (bdash)]

If this is a libxml2 bug like you claim then I would recommend constructing a test case that reproduces the problem using libxml2 directly and then filing the bug report with the libxml2 folks.  libxml2 is not part of WebKit, so unless the problem is in the manner that libxml2 uses WebKit there’s nothing for us to do here.

[Johnny(Jianning) Ding]

Thanks Mark!
I am preparing to file a bug to libxml2. But I think both libxml2 and WebKit all need to change.

I use xmllint(libxml2 v2.7.6) to debug the parser of libxml2 by using push mode (WebKit also uses push mode), the results are good for my above test case, no multiple cdata sections are generated. After digging in the libxml2 code, I found different behaviorbetween libxml2 default SAX cdataBlock handler and WebKit XMLTokenizer::cdataBlock.

In libxml2 default SAX cdataBlock (SAX2.c, line 2679), it checked whether last child node was CDATA section. If yes, it appended the current contents of CDATA section to the last CDATA section node. If not, it created a new CDATA section node. That was why there was no multiple CDATA section generated by xmllint. But this behavior would cause another issue, multiple adjacent CDATA sections would automatically combine to one single CDATA sections, which also did not exactly reappear the original xml structure.

In XMLTokenizer::cdataBlock(XMLTokenizerlibxml2.cpp, line 956), it didn't check whether the previous node (last child node) was CDATA section and try to merge them if yes. So WebKit got multiple CDATA sections for single CDATA section.

I will file a bug to libxml2 to propose solutions to let libxml2 parse out exact reappearance of the original xml structure. Then may change the XMLTokenizer::cdataBlock to correct the wrong behavior.

[Johnny(Jianning) Ding]

libxml2 bug:https://bugzilla.gnome.org/show_bug.cgi?id=610802

[Mark Rowe (bdash)]

Thanks!

[James Martin]

Thanks Johnny, The information you provide is very useful for me. (http://www.cygnismedia.com/web-application/)

[Mark Steve]

I agree with Mark Rowe, I have same kind of problem(http://www.ieventapp.com/android-event-app/) and i used this technique which gives Mark Rowe and it provides me positive result.