parseString callback never called about node-xml2js HOT 25 CLOSED

Reminds me of bug-report #3. I'll look into it but most likely this is caused by a bug in sax-js.

from node-xml2js.

I'm having this issue as well with invalid xml.

from node-xml2js.

Bugs with invalid XML are most likely a bug in sax-js, resulting in error callback being never called.

from node-xml2js.

I ran into a similar issue with xml input that omitted the close element for the root tag. It looks like there are two underlying concerns. First, as noted above, node-sax version 0.4.2 and 0.4.3 do not properly return errors in this situation. Starting with version 0.5.0 that appears to have been remedied. So, for starters, a bump to 0.5.0 (minimum) would be helpful.

In addition, I believe xml2js itself should be calling the close method on the underlying sax parser object immediately after calling write with the input string. This allows the parser to detect the unclosed root tag and return an error. I've tried all three cases (the two above and my malformed xml) and all three are properly handled after making those changes.

from node-xml2js.

That is a good point. Waht I'll do is release the current code with the current version that is tested and then bump to 0.5.0 on GitHub so there will be some time to determine whether there are regressions.

from node-xml2js.

@jlfaber Could you provide some testcases that are fixed when using the close method, so I can add a regression test?

from node-xml2js.

With 0.5.0, I believe the two listed above (foo.xml and foo2.xml) should both be fixed (i.e. return errors), as should the following simple case:

foo3.xml

<?xml version="1.0"?>
<unclosedRootTag>

Not sure what just adding the close() without bumping 0.5.0 is going to do. Guess that's what testing is for...

Also, I scanned the delta between 0.5.0 and 0.5.4 (current) and all the changes look pretty benign. I'd suggest using a more permissive dependency specification like "0.5.x" rather than locking into a specific version, as recommended here: http://blog.nodejitsu.com/package-dependencies-done-right. I realize there's some level of trust required to do that (specifically that the dependent module author will respect semver and not introduce incompatible changes), but it certainly makes it easier to pick up bug fixes. Thanks for the quick response, btw!

from node-xml2js.

I'll add the close() later, I broke my finger so lately maintenance has been quite slow.

I used to have something like >= x.y.z but that didn't work so well, I even got a bug report, #68. The problem was that I often got bug reports that I just couldn't reproduce because they were (maybe) using a broken version of sax-js, so I pinned it to the version that I have tested it. I usually bump the versions before releasing.

So, it is kinda difficult. Maybe sax-js got more mature so I could try using a 0.5.x restriction, I should think about it some more.

from node-xml2js.

I agree that ">= x.y.z" is problematic since it allows both the major and minor versions to increase as well as the patch version. If the sax author is properly following the semver.org rules, though, allowing "0.5.x" should be safe since only the patch version is allowed to increase. And by contract, that means that the public API has not changed.

I understand the danger of bugs in future versions of sax But that has to be balanced against the danger of undiscovered bugs in the current version of sax. When that happens (and there are ALWAYS undiscovered bugs), if the sax version is pinned, I need not only to get the bug fixed in sax, but I have to trouble you to update your module as well to pick up that change. For any component with more than a couple of dependencies, that will quickly turn into a mess! Specifying a particular major and minor version, but allowing patch to float is much more scalable IMO.

from node-xml2js.

Is there a way to specify "0.5.x where x > 3" or something?

from node-xml2js.

I think you can use a tilde version spec for that. "~0.5.4" is technically equivalent to ">=0.5.4 <0.6.0". See the docs here: https://npmjs.org/doc/json.html

from node-xml2js.

I'm having this issue too. The close() after the write in parseString solves it.

from node-xml2js.

@guillermosan Can you post a simple XML file that fails without the close() and succeeds with it? I could add a regression test for it. When I just add close() the testsuite basically explodes, I need to look into it what's wrong.

from node-xml2js.

@Leonidas-from-XIV There you go, but no new info. It's the same @jlfaber posted.

<?xml version="1.0"?>
<unclosedRootTag>

Without close() this will make parseString to never call the callback. With the close() it will call the cb with error "Unclosed root tag".

from node-xml2js.

Alright. Unfortunately, it also crashes a lot of unit tests which use well-formed XML.

from node-xml2js.

@Leonidas-from-XIV I'm having that issue right now with version 0.4.6 that is latest:

[Error: Unclosed root tag
Line: 0
Column: 15
Char: ]

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Unclosed root tag
Line: 0
Column: 15
Char:
    at error (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/node_modules/sax/lib/sax.js:642:8)
    at strictFail (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/node_modules/sax/lib/sax.js:662:22)
    at end (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/node_modules/sax/lib/sax.js:649:27)
    at Object.write (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/node_modules/sax/lib/sax.js:916:30)
    at Object.SAXParser.close (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/node_modules/sax/lib/sax.js:152:38)
    at Parser.exports.Parser.Parser.processAsync (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/lib/xml2js.js:249:31)
    at Object._onImmediate (/Users/dmitri/trinity-mirror/football-modular/football-betting-api/node_modules/xml2js/lib/xml2js.js:6:59)
    at processImmediate [as _immediateCallback] (timers.js:354:15)

That's very annoying 'cause it crashes the app and I have no chance to intercept it in callback of parseString.

from node-xml2js.

Can you post a simple XML to reproduce?

from node-xml2js.

@Leonidas-from-XIV just try '<xml>POST VALUE'.

from node-xml2js.

@Leonidas-from-XIV I know that xml is extremely invalid but I'm working with resource that can send crazy responses..

from node-xml2js.

You can take the xml in blocks and if find any new line then add into the block if index goes to - then console you will find full xml then use it like
var callbackres = callbackresxml.toString('utf8');
callbackblock += callbackres;
if(callbackres.indexOf("\n")> -1){console.log(callbackblock );}

from node-xml2js.

Even I am facing 'Unclosed Root Tag' error for valid XML. The version of library I am using is 0.4.4. Was anyone able to find workaround for this?

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Unclosed root tag
Line: 1098
Column: 274
Char: 
    at error (/home/user/user/Test/node_modules/xml2js/node_modules/sax/lib/sax.js:642:8)
    at strictFail (/home/user/user/Test/node_modules/xml2js/node_modules/sax/lib/sax.js:662:22)
    at end (/home/user/user/Test/node_modules/xml2js/node_modules/sax/lib/sax.js:649:27)
    at Object.write (/home/user/user/Test/node_modules/xml2js/node_modules/sax/lib/sax.js:916:30)
    at Object.SAXParser.close (/home/user/user/Test/node_modules/xml2js/node_modules/sax/lib/sax.js:152:38)
    at Parser.exports.Parser.Parser.parseString (/home/user/user/Test/node_modules/xml2js/lib/xml2js.js:403:67)
    at Parser.parseString (/home/user/user/Test/node_modules/xml2js/lib/xml2js.js:6:61)
    at Socket.<anonymous> (/home/user/user/Test/ftpfileSaveWorker.js:43:20)
    at Socket.emit [as _emit] (events.js:95:17)
    at Socket.source.emit (/home/user/user/Test/node_modules/ftp/lib/connection.js:564:20)

from node-xml2js.

from node-xml2js.

This is happening to me as well using the following xml:

<root>Hello xml2js!</root>

I am using FS to parse a file from a local path; when I console.log the data from fs readFile then I get a buffer. Can parseString handle buffers? If not, I'd posit a guess that's the problem.

var asset_hitboxes;
var parser = new xml2js.Parser();
fs.readFile(__dirname + '/assets_test.xml', function(err, data) {
    parser.parseString(data, function (err, result) {
		asset_hitboxes = result;
        console.dir(err, result);
        console.log('Done');
    });
});

from node-xml2js.

Yah actually well, I was pointing to the wrong file xD buuuuuuuuuuuuut it seems that there was still a problem parsing the buffer. this code seems to work assuming my above quoted xml:

var asset_hitboxes;
var parser = new xml2js.Parser();
fs.readFile(__dirname + '/assets_test.xml', "utf-8", function(err, data) {
	console.log(data)
    parser.parseString(data, function (err, result) {
		asset_hitboxes = result;
        console.dir(err, result);
        console.log('Done');
    });
});

Note: the utf-8 is the important part

from node-xml2js.

fs don't work , how to customise

from node-xml2js.