in reply to RPC::XML server seems to occasionally send corrupted responses

This looks like a bug in the RPC::XML::Server module related to compression.

Here's what's going on. The server decides it needs to compress the response data because it's over the compress_thresh threshold (defaults to 4 kB). It does this fine as you've discovered in the packet trace but what it's not doing is sending a Content-Type response header of deflate (in fact, it tries to set it but the value of $compress is never assigned). This causes the client to not know that it needs to filter the response through Compress::Zlib and fails silently when it tries to parse the XML. To overcome this, you can set the compress_thresh manually to an arbitrarily large number so the server never thinks it needs to compress the response. Otherwise you'll need to patch the RPC/XML/Server.pm file yourself so that the server sends the correct response header.

Basically all you need to do is add a $compress = $self->compress to the section of the code that compresses the response xml. (diff follows) 
*** 1351,1356 ****
--- 1351,1357 ----
          }
          elsif ($req->method eq 'POST')
          {
+                       $compress = $self->compress;
              # Get a XML::Parser::ExpatNB object
              $parser = $self->parser->parse();
This code is already in the Apache::RPC::Server module that is included in this package so I'm sure it's just an oversight on the part of the module writer.

HTH - brian

Replies are listed 'Best First'.
Re^2: RPC::XML server seems to occasionally send corrupted responses
by nenbrian (Acolyte) on Sep 28, 2004 at 18:44 UTC

    Thanks Brian, that's very helpful.

    Is there a way to explicitly turn compression off? There doesn't seem to be a documented way to do this (short of setting the compress_thresh parameter to something really high, as you suggested).

    Thanks again,
    -brian

[reply]
      I just peeked at the source code and it appears that you can pass in a no_compress => 1 option when you're creating the server object. This isn't included in any of the documentation unfortunately. Give it a shot...
[reply]
[d/l]

        Yea, we saw that too, but setting the no_compress option in the server didn't seem to work.

        Thanks very much for all of your insightful help. That seems to have worked around the problem. I have e-mailed the maintainer of the package with your suggested fix, and (hopefully) our data parameters will never get bigger than the threshold (2^31 bytes) that we have set before the bug fix is released! :-)

        Thanks again,
        -nenbrian

[reply]

In Section Seekers of Perl Wisdom