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

Request deserialisation issue

Expand Messages
  • jmglov027
    I work on a three-tier application in which Perl code running on webservers uses SOAP::Lite to communicate with Perl code running on appservers. I am not using
    Message 1 of 4 , May 23, 2005
    • 0 Attachment
      I work on a three-tier application in which Perl code running on
      webservers uses SOAP::Lite to communicate with Perl code running on
      appservers. I am not using many of SOAP::Lite's features--it is pretty
      much just serving as a serialiser of Perl datatypes.

      Everything works well with SOAP::Lite 0.60, with the exception of an
      occasional "Cannot locate method 'foo' in class 'Foo::Bar'" error. I
      am guessing this is related to a stack corruption bug in SOAP::Lite
      that was apparently fixed in 0.63.

      I upgraded both client and server to SOAP::Lite 0.65_5, and was
      delighted when the webserver code was able to login and create a
      session by calling an appserver method using SOAP, then display a main
      portal page with a series of SOAP calls.

      However, that is as far as my luck held. Attempting to display other
      pages within the application resulted in the following SOAP fault:

      soap:Client (Application failed during request deserialization: not
      well-formed (invalid token) at line 1, column 26427, byte 26427 at
      /usr/local/lib/perl5/site_perl/5.8.3/i86pc-solaris/XML/Parser.pm line
      187 )

      In an attempt to figure out why the XML is malformed (and which
      client-side SOAP call is to blame), I stuck the following at the top
      of my SOAP server script (I am using mod_perl and
      SOAP::Transport::HTTP::Apache):

      use SOAP::Lite +trace => 'all';

      This has the desired effect of producing some useful spew in the
      Apache error log, and I can see where the error is ocurring, but the
      XML itself is not being logged. Any idea why that is the case?

      And, in a broader sense, have other people noticed breakage when
      upgrading SOAP::Lite similar to what I am experiencing?

      Of course, if anyone else has seen sporadic "Failed to locate method"
      errors with a SOAP::Transport::HTTP::Apache->dispatch_to() setup, I
      would be interested in how you resolved them. If upgrading SOAP::Lite
      is not necessary, I would like to avoid it, so that I don't have to
      deal with strange XML-related errors like I have described above.

      Thanks in advance,
      Josh

      PS: I will be happy to provide more details about my installation and
      architecture as needed. I tried to provide a reasonable amount of
      information in this email without overwhelming anyone.
    • jmglov027
      ... This turned out to be an errant & that was living in a URL that was being passed as part of the SOAP message body. The real question is, why was the
      Message 2 of 4 , May 24, 2005
      • 0 Attachment
        --- In soaplite@yahoogroups.com, "jmglov027" <josh.glover@t...> wrote:

        > I upgraded both client and server to SOAP::Lite 0.65_5, and was
        > delighted when the webserver code was able to login and create a
        > session by calling an appserver method using SOAP, then display a
        > main portal page with a series of SOAP calls.
        >
        > However, that is as far as my luck held. Attempting to display other
        > pages within the application resulted in the following SOAP fault:
        >
        > soap:Client (Application failed during request deserialization: not
        > well-formed (invalid token) at line 1, column 26427, byte 26427 at
        > /usr/local/lib/perl5/site_perl/5.8.3/i86pc-solaris/XML/Parser.pm
        > line 187 )

        This turned out to be an errant '&' that was living in a URL that was
        being passed as part of the SOAP message body.

        The real question is, why was the older version of SOAP::Lite
        apparently escaping the ampersand properly, and the newer version not?

        -Josh
      • jmglov027
        ... And the plot thickens. The SOAP call looks like this: $soap- set( { data = $data }, foo , [ data ], { ses_id = foo }, { _no_data = 1 } ) $data is
        Message 3 of 4 , May 24, 2005
        • 0 Attachment
          --- In soaplite@yahoogroups.com, "jmglov027" <josh.glover@t...> wrote:
          > --- In soaplite@yahoogroups.com, "jmglov027" <josh.glover@t...> wrote:
          >
          > > I upgraded both client and server to SOAP::Lite 0.65_5 [...]
          > > Attempting to display other pages within the application resulted
          > > in the following SOAP fault:
          > >
          > > soap:Client (Application failed during request deserialization: not
          > > well-formed (invalid token) at line 1, column 26427, byte 26427 at
          > > /usr/local/lib/perl5/site_perl/5.8.3/i86pc-solaris/XML/Parser.pm
          > > line 187 )
          >
          > This turned out to be an errant '&' that was living in a URL that
          > was being passed as part of the SOAP message body.

          And the plot thickens. The SOAP call looks like this:

          $soap->set( { data => $data }, "foo", [ "data" ],
          { ses_id => "foo" }, { _no_data => 1 } )

          $data is itself a reference to a hash, the contents of which are (in
          Data::Dumper notation):

          0 HASH(0x8eeaa2c)
          'cli_tz' => 'America/New_York'
          'core' => HASH(0x8eebc94)
          'core' => undef
          'email' => undef
          'ext_dialing' => undef
          'fax' => undef
          'hosted' => undef
          'inbound' => undef
          'manual' => undef
          'mapping' => undef
          'outdial' => undef
          'page' => undef
          'feature_url' =>
          'http://localhost/portal.cgi?rm=feature&fid=2100&sid=foo'
          'sec_group' => 39
          'sys_features' => ARRAY(0x8efc820)
          0 HASH(0x8efe0c8)
          'cli_id' => 2048
          'f_id' => 1000
          'f_level' => 2
          'f_name' => 'Feature Control'
          'f_num' => 3244
          'f_order' => 0
          'height' => undef
          'img' => undef
          'par_id' => 0
          'prf_id' => 84
          'prf_name' => 'admin'
          'status' => 1
          'uri' => undef
          'width' => undef
          'wizard' => 0

          [...]

          19 HASH(0x8f22b2c)
          'cli_id' => 2048
          'f_id' => 3106
          'f_level' => 4
          'f_name' => 'Advanced Contact Management'
          'f_num' => 3260
          'f_order' => 0
          'height' => undef
          'img' => undef
          'par_id' => 2100
          'prf_id' => 84
          'prf_name' => 'admin'
          'status' => 1
          'uri' => 'contact_management.cgi?rm=contact&delete=y'
          'width' => undef
          'wizard' => 0

          The ampersand in $data->{feature_url} is what is causing the
          deserialisation fault on the SOAP server side. I have verified this by
          turning on tracing on the client side and looking at the XML produced
          by the serialiser.

          The strange thing is that $data->{sys_features}->[19]->{uri} also
          contains an ampersand, but this one is being escaped properly, i.e the
          XML value is "contact_management.cgi?rm=contact&delete=y".

          Any ideas why the ampersand in $data->{feature_url} is not being
          escaped, while the other one is?

          -Josh
        • Duncan Cameron
          ... not ... At some point in the S::L 0.65_x releases anyURI was added to the list of autodetected types, so something which looks like a URI (begins with
          Message 4 of 4 , May 25, 2005
          • 0 Attachment
            At 2005-05-24, 22:51:10 you wrote:

            >--- In soaplite@yahoogroups.com, "jmglov027" <josh.glover@t...> wrote:
            >> --- In soaplite@yahoogroups.com, "jmglov027" <josh.glover@t...>
            wrote:
            >>
            >> > I upgraded both client and server to SOAP::Lite 0.65_5 [...]
            >> > Attempting to display other pages within the application resulted
            >> > in the following SOAP fault:
            >> >
            >> > soap:Client (Application failed during request deserialization:
            not
            >> > well-formed (invalid token) at line 1, column 26427, byte 26427 at
            >> > /usr/local/lib/perl5/site_perl/5.8.3/i86pc-solaris/XML/Parser.pm
            >> > line 187 )
            >>
            >> This turned out to be an errant '&' that was living in a URL that
            >> was being passed as part of the SOAP message body.
            >
            >And the plot thickens. The SOAP call looks like this:
            >
            >$soap->set( { data => $data }, "foo", [ "data" ],
            > { ses_id => "foo" }, { _no_data => 1 } )
            >
            >$data is itself a reference to a hash, the contents of which are (in
            >Data::Dumper notation):
            >
            >0 HASH(0x8eeaa2c)
            > 'cli_tz' => 'America/New_York'
            > 'core' => HASH(0x8eebc94)
            > 'core' => undef
            > 'email' => undef
            > 'ext_dialing' => undef
            > 'fax' => undef
            > 'hosted' => undef
            > 'inbound' => undef
            > 'manual' => undef
            > 'mapping' => undef
            > 'outdial' => undef
            > 'page' => undef
            > 'feature_url' =>
            >'http://localhost/portal.cgi?rm=feature&fid=2100&sid=foo'
            > 'sec_group' => 39
            > 'sys_features' => ARRAY(0x8efc820)
            > 0 HASH(0x8efe0c8)
            > 'cli_id' => 2048
            > 'f_id' => 1000
            > 'f_level' => 2
            > 'f_name' => 'Feature Control'
            > 'f_num' => 3244
            > 'f_order' => 0
            > 'height' => undef
            > 'img' => undef
            > 'par_id' => 0
            > 'prf_id' => 84
            > 'prf_name' => 'admin'
            > 'status' => 1
            > 'uri' => undef
            > 'width' => undef
            > 'wizard' => 0
            >
            >[...]
            >
            > 19 HASH(0x8f22b2c)
            > 'cli_id' => 2048
            > 'f_id' => 3106
            > 'f_level' => 4
            > 'f_name' => 'Advanced Contact Management'
            > 'f_num' => 3260
            > 'f_order' => 0
            > 'height' => undef
            > 'img' => undef
            > 'par_id' => 2100
            > 'prf_id' => 84
            > 'prf_name' => 'admin'
            > 'status' => 1
            > 'uri' => 'contact_management.cgi?rm=contact&delete=y'
            > 'width' => undef
            > 'wizard' => 0
            >
            >The ampersand in $data->{feature_url} is what is causing the
            >deserialisation fault on the SOAP server side. I have verified this by
            >turning on tracing on the client side and looking at the XML produced
            >by the serialiser.
            >
            >The strange thing is that $data->{sys_features}->[19]->{uri} also
            >contains an ampersand, but this one is being escaped properly, i.e the
            >XML value is "contact_management.cgi?rm=contact&delete=y".
            >
            >Any ideas why the ampersand in $data->{feature_url} is not being
            >escaped, while the other one is?
            >
            >-Josh

            At some point in the S::L 0.65_x releases 'anyURI' was added to the
            list of autodetected types, so something which looks like a URI (begins
            with http:// or urn:) will be typed as xsi:type="xsd:anyURI".
            The error seems to be that the value of the uri is not being escaped.
            The method as_anyURI simply returns the value passed to it. I had a
            quick go at changing the code but couldn't figure out exactly which
            bits to modify.

            I had a quick look in the Changes file but couldn't see any reference
            to this change.

            In your example, the second uri does not actually begin with http:// so
            it is not being autotyped and is treated as a string.

            Duncan








            ___________________________________________________________
            Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
          Your message has been successfully submitted and would be delivered to recipients shortly.