use IO::File;
...
my $fileStream = new IO::File ("yourDocumentName.xml");
...
my $parser = new XML::Parser 
   ( Handlers => 
      {   # Creates our parser object
         Start   => \&hdl_start,
         End     => \&hdl_end,
         Char    => \&hdl_char,
         Default => \&hdl_def,
      }
   );
...
$parser->parse($fileStream);
[download]

$parser->parsefile($filename)
[download]

Hi,

Anyone facing xml bomb issue with the below mentioned code which was discussed above?

my $parser = new XML::Parser 
   ( Handlers => 
      {   # Creates our parser object
         Start   => \&hdl_start,
         End     => \&hdl_end,
         Char    => \&hdl_char,
         Default => \&hdl_def,
      }
   );
...
$parser->parse($fileStream);
[download]

It would be very helpful if anyone could help me to resolve this xml bomb issue..

Is xml bomb issue applicable for this XML::Parser module? Can anyone shed some light on this?

-- Nagalakshmi

What you call "xml bomb" is most likely the XML Entity Expansion attack.

This is most easily prevented by not expanding entities, or not expanding them recursively.

To enable that, see the XML::Parser documentation, especially the NoExpand flag and the handlers for external and other entities.

In those, you get to decide whether to fetch them and whether to expand them. If an entity expands to more entities, consider whether to expand them or not.

Is there some clean way how to subclass XML::Parser?

The problem is probably that XML::Parser is an object factory: it generates XML::Parser::Expat objects with each parse or parsefile call. The handlers then receive XML::Parser::Expat objects and not XML::Parser objects.

There is a way to store data in the XML::Parser object and to access it in the handlers though: use the 'Non-Expat-Options' argument when creating the XML::Parser:

#!/bin/perl -w
use strict;
use XML::Parser;

my $p= new XML::Parser(
        'Non-Expat-Options' => { my_option => "toto" },
        Handlers => { Start => \&start, }
                      );
$p->parse( '<a />');

sub start
  { my( $pe, $elt, %atts)= @_;
    print "my option: ", $pe->{'Non-Expat-Options'}->{my_option}, "\n"
+;
  }
[download]

This is certainly ugly but it works!

Update: note that the data is still stored in the XML::Parser object though, as shown by this code:

#!/bin/perl -w
use strict;
use XML::Parser;

my $p= new XML::Parser(
        'Non-Expat-Options' => { my_option => "1" },
        Handlers => { Start => \&start, }
                      );
$p->parse( '<a />');
$p->parse( '<b />');

sub start
  { my( $pe, $elt, %atts)= @_;
    print "element: $elt - my option: ", 
          $pe->{'Non-Expat-Options'}->{my_option}++, "\n";
    $p->parse( '<c />') 
       unless( $pe->{'Non-Expat-Options'}->{my_option} > 3);
  }
[download]

Which outputs:

element: a - my option: 1
element: c - my option: 2
element: c - my option: 3
element: b - my option: 4
[download]

Why do you want to subclass it? It works much better as a "has-a" than an "is-a", unless you want to get very cozy from the base class implementation, which is a maze of twisty tiny packages all alike.

Just delegate the methods that you want to provide in your interface, and handle the rest. Make a hash with one of the elements being your "inherited" parser. I believe it's called the "wrapper" pattern, but I don't name my patterns—I just use them!

-- Randal L. Schwartz, Perl hacker

Well, but .... (there is allways a 'but') :-)

Suppose I do not subclass XML::Parser. But then, how do I pass parameters to XML::Parser handler methods and collect results of their run without using global variables of XML::Parser package? Only class that I get to handler methods is expat itself and there is no place for any aditional parameters/results of handler methods.

And if I subclass XML::Parser, only advantage that I gain is using my own package namespace for global variables instead of XML::Parser's namespace. This do not looks to me like a good example of object oriented programming style.

Possible silution is the one mirod suggested using Non-Expat-Options but it is just a little bit less ugly than these two.

There best solution will be forcing XML::Parser to use my custom subclass of XML::Parser::Expat instead of XML::Parser::Expat itself. Is there some way how to do that?

The first rule of XML::Parser's use: Don't. Or rather, don't use it directly. Unless you really must which is much less often than you might think.

#!/usr/bin/perl -w
use strict;
use XML::Rules;

use LWP::Simple;  # used to fetch the chatterbox ticker

my $cb_ticker = get("http://perlmonks.org/index.pl?node=chatterbox+xml
++ticker");

my $parser = XML::Rules->new(
    stripspaces => 7,
    rules => {
        message => sub {
            my ($tag, $atts) = @_;
            $atts->{'_content'} =~ s/\n//g;

            my ($y,$m,$d,$h,$n,$s) = $atts->{'time'} =~ m/^(\d{4})(\d{
+2})(\d{2})(\d{2})(\d{2})(\d{2})$/;

            # Handles the /me
            $atts->{'_content'} = $atts->{'_content'} =~ s/^\/me// ?
            "$atts->{'author'} $atts->{'_content'}"   :
            "<$atts->{'author'}>: $atts->{'_content'}";
            $atts->{'_content'} = "$h:$n " . $atts->{'_content'};
            print "$atts->{'_content'}\n";
            return;
        },
        'INFO,CHATTER' => 'pass',
    }
);

$parser->parse($cb_ticker);
[download]

Isn't this easier? Now imagine the <message> tag was not so simple, imagine it contained a structure of subtags and subsubtags. Your handlers would have to keep track of where in the structure the parser is and would have to build the datastructure containin that data so that finaly they can access it in the endtag handler if and only iff the tag is <message>. Not what I would call convenient.

With XML::Rules you'd just specify what tags do you want to include (and whether they are supposed to be repeated, contain text content etc. ... the rules may be infered from a DTD or example) and assign a handler specificaly to the <message> tag. And the handler will have access to the datastructure built from the subtags.

With XML::Twig you'll specify the twig_root (or something, I don't remember details) and again will assign a handler to the specific tag and receive all the data from the part of the XML enclosed in it.

And in neither case does the parser have to parse the whole file before your handlers are started and at no time is the whole parsed XML in the memory. (Well, if you use the modules correctly.)

Jenda, was that in response to my message?
I can't tell if it was or not because it uses the example from the main post, not the one I had.


Mike

No it was a response to the root node. For your problem ... show us your code. It's true that the Char handler will never be called, but both the Start and End handlers should. In either case you of course can use XML::Rules for that XML as well, specify a handler for the student tag and it will obtain all the attributes. Or, it you do not need to handle the individual <student> tags as you read them, specify student => 'as array', or possibly student => 'by name', in the rules. And handle the array of students in $attr->{student} or access the individual students as $attr->{$name} (depends on the rule you specify for <student>) in the handler for <class>.

Jenda


Support Denmark! Defend the free world!

There is a rule regarding XML (you may hate it), if the XML is not well-formed (all the tags matching up and correctly nested), then the parser should stop fatally.

So if you try and parse a file that isn't well-formed XML you will discover this very quickly as the parser will die. (This is incientally a quick way of figuring out if a file is XML.)

Davorg gives a good example here: Re: Is a file XML?. Basically you eval the parse call to trap the die, then do what you want afterwards.

   <class>
      <student name="Student1" race="Fast" age="Std" />
      <student name="Student2" race="Slow" age="New" />
      <student name="Student3" race="Okay" age="Old" />
   </class>
[download]

search for parsing xml attributes. I'm trying to figure out a similar parsing issues. It appears that these are xml elements with no values, only attributes? I haven't been able to find much on this.

How can I select data that's nested but have the same tag names in another section of the xml? With the xml formed like this, the parser will get all information tagged with "message", rather than getting just ones in "urgent" and/or "update". Should I just start another parse instance in the start handler?

<MAILBAG>
    <urgent>
        <message author="PatrickHenry" time="20010228212953">Now is th
+e time for all good men to come to the aid of their party.</message>
    </urgent>
    <update>
        <message author="OeufMayo" time="20010228112952">test</message
+>
        <message author="deprecated" time="20010228113142">pong</messa
+ge>
    </update>
</MAILBAG>
[download]

The easiest thing to do would be to not use XML::Parser directly. Otherwise you'd have to keep track of what start/end tags you've seen.

Yes perfect! I knew there had to be a better way. Thanks!

I know this is a very old post, but in case anyone arrives here via Google, I wanted to note that this tutorial is misguided. There's absolutely no reason whatsoever to use XML::Parser, and the code above is needlessly complex. There's also about three times as much code as you need for something this simple. So why not use XML::Simple? It's pretty straightforward:

use warnings;
use strict;

use XML::Simple;

# Just an example. You'd use LWP to get the actual CB.
my $xml = '<CHATTER><INFO site="http://perlmonks.org" sitename="Perl M
+onks">Rendered by the Chatterbox XML Ticker</INFO>
    <message author="OeufMayo" time="20010228112952">test</message>
    <message author="deprecated" time="20010228113142">pong</message>
    <message author="OeufMayo" time="20010228113153">/me test again; :
+)</message>
    <message author="OeufMayo" time="20010228113255">&lt;a href="#"&gt
+;please note the use of HTML tags&lt;/a&gt;</message></CHATTER>';

my $ref = XMLin($xml);

foreach my $msg (@{$ref->{'message'}}) {
  my $h = substr($msg->{'time'}, 8, 2);
  my $n = substr($msg->{'time'}, 10, 2);

  my $author = $msg->{'content'} =~ s/^\/me// ? $msg->{'author'} : "<$
+msg->{'author'}>";
  print "$h:$n $author: $msg->{'content'}\n";
}
[download]

So why not use XML::Simple?

Because the module author advises against it. From the XML::Simple POD (STATUS OF THIS MODULE):

The use of this module in new code is discouraged. Other modules are available which provide more straightforward and consistent interfaces. In particular, XML::LibXML is highly recommended.

The major problems with this module are the large number of options and the arbitrary ways in which these options interact - often with unexpected results.

Patches with bug fixes and documentation fixes are welcome, but new features are unlikely to be added.

Please see also XML::LibXML::Simple for a handy replacement for XML::Simple:

Read more... (2 kB)

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

Please see also XML::LibXML::Simple for a handy replacement for XML::Simple:

:) nope, XML::Rules is a handy replacement for XML::Simple