Loading ...
Sorry, an error occurred while loading the content.

4479RE: [soaplite] Re: Server state not cleared after fault?

Expand Messages
  • Jon Kliegman
    Mar 12, 2005
    • 0 Attachment
      Message
       
      -----Original Message-----
      From: mitchbetterhavemybunny [mailto:mitchbetterhavemybunny@...]
      Sent: Friday, March 11, 2005 5:27 PM
      To: soaplite@yahoogroups.com
      Subject: [soaplite] Re: Server state not cleared after fault?


      --- In soaplite@yahoogroups.com, "mitchbetterhavemybunny"
      <mitchbetterhavemybunny@y...> wrote:
      >
      > I'm having some strange and unsettling troubles with a SOAP::Lite
      > server in a mod_perl environment.  I think that SOAP::Lite may not
      > re-initialize properly after serving a SOAP fault.
      > ...
      > Is it really possible that SOAP::Lite does not clear its state for
      > each new request?  I'm a little skeptical that I'm seeing what I think
      > I'm seeing, since nobody else appears to be freaking out about this.
      > Has anyone ever seen this before?
      >

      Well, as it turns out, somebody else did freak out, and they also
      posted a workaround.  This was reported as bug #933484 for the
      SOAP::Lite project on sourceforge
      (http://sourceforge.net/tracker/index.php?func=detail&aid=933484&group_id=66000&atid=513017).

      Scott Franklin

      There is a bug in SOAP::Lite 0.55 where certain mal-formed XML packets will cause the SOAP server to use the previous, succesful XML packet.  Basically the SOAP parser does not clear state on certain failures in the XML parser (some failures are handled correctly) and the next time a packet comes in it is not processed but instead returns data from the original, valid request.  The sequencing looks like this (this all has to happen on the same process ID so forcing a specific failure in a production environment is difficult) : 
        Client A sends Request A and gets Response A
        Client B sends mal-formed XML and gets failure
        Client C sends Request C and gets Response A'
       
      Note that the response Client C gets is actually Request A reprocessed - it is not a copy of the original response.  And in the case where Request C and Request A are different operations Client C will get a fault stating that the SOAPAction header did not match the actual request.
       
      The workaround I posted will cause the state to be fully reset after Client B sends a mal-formed XML packet.  However the data of the original Request A will still be in memory (this was the most expedient way to return a production system to working).  There may be other bugs which could trigger this that I did not detect.
       
      If you'd like, you can contact me directly and I will provide the test code I have which reproduces this situation (it is reproduceable when running SOAP::Line in a standalone server setup).  I do not want to publically publish the test code as it would allow a malicous person to access data that is not theirs.  
       
      -Jon
       
      Patch information below:
      ----------------------------
      # diff -u Lite.pm.orig Lite.pm
      --- Lite.pm.orig Wed Apr 7 23:16:58 2004
      +++ Lite.pm Sun Apr 11 19:05:18 2004
      @@ -1255,7 +1255,15 @@
      End => sub { shift; $self->end(@_) },
      Char => sub { shift; $self->char(@_) },
      );
      - $self->parser->parse($_[0]);
      + my $ret = undef;
      + eval {
      + $ret = $self->parser->parse($_[0]);
      + };
      + if ($@) {
      + $self->final; # Clean up in the event of an error
      + die $@; # Pass back the error
      + }
      + return $ret;
      }

      sub final {
      ----------------------------
    • Show all 3 messages in this topic