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

on_fault

Expand Messages
  • Ray Rizzuto
    Hi! I d like to be able to handle all errors from a soap call, including transport errors, after the call completes. I ve set the following fault handler,
    Message 1 of 9 , Feb 13, 2001
    • 0 Attachment
      Hi!

      I'd like to be able to handle all errors from a soap call, including
      transport errors, after the call completes. I've set the following
      fault handler, which almost works except that the faultstring isn't
      available after the call to the method:

      sub fault
      {
      my($soap, $res) = @_;
      if (defined $res && ref $res)
      {
      print $res->faultstring;
      return $res;
      }
      else
      {
      print $soap->transport->status;
      $res = new SOAP::SOM;
      $res->faultstring("transport error");
      return $res;
      }
      }


      Here's the call and the test of faultstring:

      my $soap = SOAP::Lite->new(
      uri =>'http://pc-rizzuto-p/Demo',
      proxy =>'http://pc-rizzuto-p:9999/',
      on_fault => \&fault);

      my $result = $soap->call('hi');

      if (!$result->faultstring)
      {
      print $result->result;
      }
      else
      {
      print $soap->faultstring;
      }

      I'm very new to this, so I may be making an obvious mistake.

      Ray
    • Paul Kulchenko
      Hi, Ray! ... Here is the reason. faultstring() and other methods are readonly. You may get access to message structure, but you cannot update/modify it. Next
      Message 2 of 9 , Feb 13, 2001
      • 0 Attachment
        Hi, Ray!

        --- Ray Rizzuto <ray.rizzuto@...> wrote:
        > I'd like to be able to handle all errors from a soap call,
        > including
        > transport errors, after the call completes. I've set the following
        > fault handler, which almost works except that the faultstring isn't
        > available after the call to the method:
        >
        > sub fault
        > {
        > my($soap, $res) = @_;
        > if (defined $res && ref $res)
        > {
        > print $res->faultstring;
        > return $res;
        > }
        > else
        > {
        > print $soap->transport->status;
        > $res = new SOAP::SOM;
        > $res->faultstring("transport error");

        Here is the reason. faultstring() and other methods are readonly. You
        may get access to message structure, but you cannot update/modify it.
        Next version probably will generate warning/error if you try to
        provide parameter(s) for these methods.

        > I'm very new to this, so I may be making an obvious mistake.

        You may check Error Handling section on http://guide.soaplite.com/. I
        prefer 2.k example and in any case you always have access to result
        of the call through call() method:

        print $soap->mymethod(123)->result;
        print $soap->call->faultstring;

        Even if call made with autodispatch:

        use SOAP::Lite +autodispatch => ...;

        print mymethod(123);
        print SOAP::Lite->self->call->faultstring;

        Best wishes, Paul.

        __________________________________________________
        Do You Yahoo!?
        Get personalized email addresses from Yahoo! Mail - only $35
        a year! http://personal.mail.yahoo.com/
      • Ray Rizzuto
        Paul, I d like to be able to handle the transport errors in the same way as faulted calls, via the fault methods of the SOAP::SOM returned from the call.
        Message 3 of 9 , Feb 13, 2001
        • 0 Attachment
          Paul,

          I'd like to be able to handle the transport errors in the same way as
          faulted calls, via the fault methods of the SOAP::SOM returned from
          the call. That's why I was trying to create a SOAP::SOM and set the
          string.

          Part of the reason for this is that transport errors may be
          transient - I'd like to retry the call later in the application I'm
          writing. My app is a gui interface to a problem tracking system. If
          the user is creating or editing a problem report, and the network
          goes down, I want them to be able to reattempt the update in a few
          minutes.

          Ray



          --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
          > Hi, Ray!
          >
          > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
          > > I'd like to be able to handle all errors from a soap call,
          > > including
          > > transport errors, after the call completes. I've set the
          following
          > > fault handler, which almost works except that the faultstring
          isn't
          > > available after the call to the method:
          > >
          > > sub fault
          > > {
          > > my($soap, $res) = @_;
          > > if (defined $res && ref $res)
          > > {
          > > print $res->faultstring;
          > > return $res;
          > > }
          > > else
          > > {
          > > print $soap->transport->status;
          > > $res = new SOAP::SOM;
          > > $res->faultstring("transport error");
          >
          > Here is the reason. faultstring() and other methods are readonly.
          You
          > may get access to message structure, but you cannot update/modify
          it.
          > Next version probably will generate warning/error if you try to
          > provide parameter(s) for these methods.
          >
          > > I'm very new to this, so I may be making an obvious mistake.
          >
          > You may check Error Handling section on http://guide.soaplite.com/.
          I
          > prefer 2.k example and in any case you always have access to result
          > of the call through call() method:
          >
          > print $soap->mymethod(123)->result;
          > print $soap->call->faultstring;
          >
          > Even if call made with autodispatch:
          >
          > use SOAP::Lite +autodispatch => ...;
          >
          > print mymethod(123);
          > print SOAP::Lite->self->call->faultstring;
          >
          > Best wishes, Paul.
          >
          > __________________________________________________
          > Do You Yahoo!?
          > Get personalized email addresses from Yahoo! Mail - only $35
          > a year! http://personal.mail.yahoo.com/
        • Paul Kulchenko
          Hi, Ray! That is perfectly right and I understand it, but for several reasons default value was chosen as die on transport and return fault on SOAP errors. You
          Message 4 of 9 , Feb 13, 2001
          • 0 Attachment
            Hi, Ray!

            That is perfectly right and I understand it, but for several reasons
            default value was chosen as die on transport and return fault on SOAP
            errors. You may easily alter this behavior (you may even specify it
            once for ALL objects in your code with GLOBAL SETTINGS), but there is
            no one-size-fit-all solution.

            I thought about doing styles, so you can choose for example, die
            style and I'll install handler for you, or warning style or error
            code style or whatever, but i think it's too complicated conception.

            Best wishes, Paul.

            --- Ray Rizzuto <ray.rizzuto@...> wrote:
            > Paul,
            >
            > I'd like to be able to handle the transport errors in the same way
            > as
            > faulted calls, via the fault methods of the SOAP::SOM returned from
            >
            > the call. That's why I was trying to create a SOAP::SOM and set
            > the
            > string.
            >
            > Part of the reason for this is that transport errors may be
            > transient - I'd like to retry the call later in the application I'm
            >
            > writing. My app is a gui interface to a problem tracking system.
            > If
            > the user is creating or editing a problem report, and the network
            > goes down, I want them to be able to reattempt the update in a few
            > minutes.
            >
            > Ray
            >
            >
            >
            > --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
            > > Hi, Ray!
            > >
            > > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
            > > > I'd like to be able to handle all errors from a soap call,
            > > > including
            > > > transport errors, after the call completes. I've set the
            > following
            > > > fault handler, which almost works except that the faultstring
            > isn't
            > > > available after the call to the method:
            > > >
            > > > sub fault
            > > > {
            > > > my($soap, $res) = @_;
            > > > if (defined $res && ref $res)
            > > > {
            > > > print $res->faultstring;
            > > > return $res;
            > > > }
            > > > else
            > > > {
            > > > print $soap->transport->status;
            > > > $res = new SOAP::SOM;
            > > > $res->faultstring("transport error");
            > >
            > > Here is the reason. faultstring() and other methods are readonly.
            >
            > You
            > > may get access to message structure, but you cannot update/modify
            >
            > it.
            > > Next version probably will generate warning/error if you try to
            > > provide parameter(s) for these methods.
            > >
            > > > I'm very new to this, so I may be making an obvious mistake.
            > >
            > > You may check Error Handling section on
            > http://guide.soaplite.com/.
            > I
            > > prefer 2.k example and in any case you always have access to
            > result
            > > of the call through call() method:
            > >
            > > print $soap->mymethod(123)->result;
            > > print $soap->call->faultstring;
            > >
            > > Even if call made with autodispatch:
            > >
            > > use SOAP::Lite +autodispatch => ...;
            > >
            > > print mymethod(123);
            > > print SOAP::Lite->self->call->faultstring;
            > >
            > > Best wishes, Paul.
            > >
            > > __________________________________________________
            > > Do You Yahoo!?
            > > Get personalized email addresses from Yahoo! Mail - only $35
            > > a year! http://personal.mail.yahoo.com/
            >
            >
            > ------------------------ Yahoo! Groups Sponsor
            >
            > To unsubscribe from this group, send an email to:
            > soaplite-unsubscribe@yahoogroups.com
            >
            >
            >


            __________________________________________________
            Do You Yahoo!?
            Get personalized email addresses from Yahoo! Mail - only $35
            a year! http://personal.mail.yahoo.com/
          • Ray Rizzuto
            Paul, There s no perfect solution to error handling since it depends so much on the application. In my case, I am choosing to treat transport errors as
            Message 5 of 9 , Feb 14, 2001
            • 0 Attachment
              Paul,

              There's no perfect solution to error handling since it depends so
              much on the application. In my case, I am choosing to treat
              transport errors as non-fatal in the belief that they can be
              retried. Application errors (faults?) hopefully don't happen, but
              when they do they probably require manual intervention.

              I think I can almost get the behavior I want with an appropriate
              on_fault handler. I have a few questions/suggestions:

              1) could you give more details on the parameters passed to the fault
              handler? And also what the fault handler can return and how that is
              used? It seems that what it returns is returned to the failed call,
              but I'm not positive.

              2) in one of the examples you provide, you are creating a new
              SOAP::SOM to return from the fault handler:

              use SOAP::Lite
              on_fault => sub { my($soap, $res) = @_;
              eval { die ref $res ? $res->faultdetail : $soap->transport-
              >status };
              return ref $res ? $res : new SOAP::SOM;
              };

              If I could set the fault values in this new SOM, I would be able to
              address errors uniformly after the original call. Or am I
              misunderstanding this code?

              3) in the above code, on a transport error @_ has 2 entries, but the
              second one seems to just have an empty string. Is that the defined
              behavior for a transport error?

              Ray

              --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
              > Hi, Ray!
              >
              > That is perfectly right and I understand it, but for several reasons
              > default value was chosen as die on transport and return fault on
              SOAP
              > errors. You may easily alter this behavior (you may even specify it
              > once for ALL objects in your code with GLOBAL SETTINGS), but there
              is
              > no one-size-fit-all solution.
              >
              > I thought about doing styles, so you can choose for example, die
              > style and I'll install handler for you, or warning style or error
              > code style or whatever, but i think it's too complicated conception.
              >
              > Best wishes, Paul.
              >
              > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
              > > Paul,
              > >
              > > I'd like to be able to handle the transport errors in the same way
              > > as
              > > faulted calls, via the fault methods of the SOAP::SOM returned
              from
              > >
              > > the call. That's why I was trying to create a SOAP::SOM and set
              > > the
              > > string.
              > >
              > > Part of the reason for this is that transport errors may be
              > > transient - I'd like to retry the call later in the application
              I'm
              > >
              > > writing. My app is a gui interface to a problem tracking system.
              > > If
              > > the user is creating or editing a problem report, and the network
              > > goes down, I want them to be able to reattempt the update in a
              few
              > > minutes.
              > >
              > > Ray
              > >
              > >
              > >
              > > --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
              > > > Hi, Ray!
              > > >
              > > > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
              > > > > I'd like to be able to handle all errors from a soap call,
              > > > > including
              > > > > transport errors, after the call completes. I've set the
              > > following
              > > > > fault handler, which almost works except that the faultstring
              > > isn't
              > > > > available after the call to the method:
              > > > >
              > > > > sub fault
              > > > > {
              > > > > my($soap, $res) = @_;
              > > > > if (defined $res && ref $res)
              > > > > {
              > > > > print $res->faultstring;
              > > > > return $res;
              > > > > }
              > > > > else
              > > > > {
              > > > > print $soap->transport->status;
              > > > > $res = new SOAP::SOM;
              > > > > $res->faultstring("transport error");
              > > >
              > > > Here is the reason. faultstring() and other methods are
              readonly.
              > >
              > > You
              > > > may get access to message structure, but you cannot
              update/modify
              > >
              > > it.
              > > > Next version probably will generate warning/error if you try to
              > > > provide parameter(s) for these methods.
              > > >
              > > > > I'm very new to this, so I may be making an obvious mistake.
              > > >
              > > > You may check Error Handling section on
              > > http://guide.soaplite.com/.
              > > I
              > > > prefer 2.k example and in any case you always have access to
              > > result
              > > > of the call through call() method:
              > > >
              > > > print $soap->mymethod(123)->result;
              > > > print $soap->call->faultstring;
              > > >
              > > > Even if call made with autodispatch:
              > > >
              > > > use SOAP::Lite +autodispatch => ...;
              > > >
              > > > print mymethod(123);
              > > > print SOAP::Lite->self->call->faultstring;
              > > >
              > > > Best wishes, Paul.
              > > >
              > > > __________________________________________________
              > > > Do You Yahoo!?
              > > > Get personalized email addresses from Yahoo! Mail - only $35
              > > > a year! http://personal.mail.yahoo.com/
              > >
              > >
              > > ------------------------ Yahoo! Groups Sponsor
              > >
              > > To unsubscribe from this group, send an email to:
              > > soaplite-unsubscribe@y...
              > >
              > >
              > >
              >
              >
              > __________________________________________________
              > Do You Yahoo!?
              > Get personalized email addresses from Yahoo! Mail - only $35
              > a year! http://personal.mail.yahoo.com/
            • Paul Kulchenko
              Hi, Ray! ... Unfortunately not only. It may depend on Server implementation also, though I tried hard to hide these details from you. Several situations are
              Message 6 of 9 , Feb 14, 2001
              • 0 Attachment
                Hi, Ray!

                --- Ray Rizzuto <ray.rizzuto@...> wrote:
                > There's no perfect solution to error handling since it depends so
                > much on the application. In my case, I am choosing to treat
                Unfortunately not only. It may depend on Server implementation also,
                though I tried hard to hide these details from you.
                Several situations are possible:
                1. 200 OK + SOAP message (normal result)
                2a. 500 Server Error + error message (not SOAP)
                2b. 400 Bad Method + error message (not SOAP)
                2c. 510 Not Extended + error message (not SOAP)
                3a. 500 Server Error + SOAP message (Fault result)
                3b. 400 Bad Method + SOAP message (Fault result)
                4. 200 OK + SOAP message (Fault result)

                2c will be handled by SOAP::Lite automatically (you won't see it, as
                well as redirect from server).
                3b and 4 are not allowed according to current spec., though there was
                long debates about using 1 and 4 instead of 1 and 3a.

                > 1) could you give more details on the parameters passed to the
                > fault handler? And also what the fault handler can return and how
                > that
                > is used? It seems that what it returns is returned to the failed
                > call, but I'm not positive.

                First, on_fault will be called unless transport returned success.
                on_fault accepts two parameters: SOAP::Lite object and deserialized
                result (exactly as you would get it after $soap->mymethod() call).
                You may return this deserialized result or create your own and it'll
                become the result of call.
                In case you returned false (on_fault(sub{})) result of the call will
                be deserialized message as if on_fault wasn't call at all (no error
                handling).

                > 2) in one of the examples you provide, you are creating a new
                > SOAP::SOM to return from the fault handler:
                >
                > use SOAP::Lite
                > on_fault => sub { my($soap, $res) = @_;
                > eval { die ref $res ? $res->faultdetail : $soap->transport-
                > >status };
                > return ref $res ? $res : new SOAP::SOM;
                > };
                >
                > If I could set the fault values in this new SOM, I would be able to
                > address errors uniformly after the original call. Or am I
                > misunderstanding this code?
                No, you're not. You cannot assign it, but you may create new SOM
                object as result of deserialization:

                use SOAP::Lite
                on_fault => sub { my($soap, $res) = @_;
                eval { die ref $res ? $res->faultdetail : $soap->transport->status
                };
                return ref $res ? $res :
                $soap->deserializer->deserialize(
                $soap->serializer->fault('Server.Transport',
                $soap->transport->status));
                };

                print SOAP::Lite->proxy('http://localhost/')->mymethod->faultstring;

                > 3) in the above code, on a transport error @_ has 2 entries, but
                > the
                > second one seems to just have an empty string. Is that the defined
                > behavior for a transport error?
                There should be deserialized message (if you got Fault response) OR
                content of the message (if message couldn't be deserialized, for
                example HTML code or some string with error message), so if you check
                and there is not refrence, you can be sure that it's pure transport
                error (and not SOAP Fault).

                Hope it helps.

                Best wishes, Paul.


                __________________________________________________
                Do You Yahoo!?
                Get personalized email addresses from Yahoo! Mail - only $35
                a year! http://personal.mail.yahoo.com/
              • Ray Rizzuto
                Paul, In your list of errors, I don t see the case I m experiencing, which is a timeout: 500 Can t connect to pc-rizzuto-p:9999 (Timeout) In that case, what
                Message 7 of 9 , Feb 14, 2001
                • 0 Attachment
                  Paul,
                   
                  In your list of errors, I don't see the case I'm experiencing, which is a timeout:
                   
                  500 Can't connect to pc-rizzuto-p:9999 (Timeout)
                   
                  In that case, what should I get as the second parameter to the fault handler?  In the debugger, @_ has length 2, and print $_[1], but print ref $_[1] returns an empty string.  Is that because the content of the response is empty?
                   
                  Ray
                   
                  P.S.  Thanks for the information on using $soap->deserializer->deserialize to create a SOM with the appropriate fault information in it.  I would never have been able to figure that out by myself!
                  -----Original Message-----
                  From: Paul Kulchenko [mailto:paulclinger@...]
                  Sent: Wednesday, February 14, 2001 12:46 PM
                  To: soaplite@yahoogroups.com
                  Subject: Re: [soaplite] Re: on_fault

                  Hi, Ray!

                  --- Ray Rizzuto <ray.rizzuto@...> wrote:
                  > There's no perfect solution to error handling since it depends so
                  > much on the application.  In my case, I am choosing to treat
                  Unfortunately not only. It may depend on Server implementation also,
                  though I tried hard to hide these details from you.
                  Several situations are possible:
                    1. 200 OK + SOAP message (normal result)
                    2a. 500 Server Error + error message (not SOAP)
                    2b. 400 Bad Method + error message (not SOAP)
                    2c. 510 Not Extended + error message (not SOAP)
                    3a. 500 Server Error + SOAP message (Fault result)
                    3b. 400 Bad Method + SOAP message (Fault result)
                    4. 200 OK + SOAP message (Fault result)

                  2c will be handled by SOAP::Lite automatically (you won't see it, as
                  well as redirect from server).
                  3b and 4 are not allowed according to current spec., though there was
                  long debates about using 1 and 4 instead of 1 and 3a.

                  > 1) could you give more details on the parameters passed to the
                  > fault handler? And also what the fault handler can return and how
                  > that
                  > is used?  It seems that what it returns is returned to the failed
                  > call, but I'm not positive.

                  First, on_fault will be called unless transport returned success. 
                  on_fault accepts two parameters: SOAP::Lite object and deserialized
                  result (exactly as you would get it after $soap->mymethod() call).
                  You may return this deserialized result or create your own and it'll
                  become the result of call.
                  In case you returned false (on_fault(sub{})) result of the call will
                  be deserialized message as if on_fault wasn't call at all (no error
                  handling).

                  > 2) in one of the examples you provide, you are creating a new
                  > SOAP::SOM to return from the fault handler:
                  >
                  >   use SOAP::Lite
                  >     on_fault => sub { my($soap, $res) = @_;
                  >       eval { die ref $res ? $res->faultdetail : $soap->transport-
                  > >status };
                  >       return ref $res ? $res : new SOAP::SOM;
                  >     };
                  >
                  > If I could set the fault values in this new SOM, I would be able to
                  > address errors uniformly after the original call.  Or am I
                  > misunderstanding this code?
                  No, you're not. You cannot assign it, but you may create new SOM
                  object as result of deserialization:

                  use SOAP::Lite
                    on_fault => sub { my($soap, $res) = @_;
                     eval { die ref $res ? $res->faultdetail : $soap->transport->status
                  };
                       return ref $res ? $res :
                         $soap->deserializer->deserialize(
                           $soap->serializer->fault('Server.Transport',
                  $soap->transport->status));
                     };

                  print SOAP::Lite->proxy('http://localhost/')->mymethod->faultstring;

                  > 3) in the above code, on a transport error @_ has 2 entries, but
                  > the
                  > second one seems to just have an empty string.  Is that the defined
                  > behavior for a transport error?
                  There should be deserialized message (if you got Fault response) OR
                  content of the message (if message couldn't be deserialized, for
                  example HTML code or some string with error message), so if you check
                  and there is not refrence, you can be sure that it's pure transport
                  error (and not SOAP Fault).

                  Hope it helps.

                  Best wishes, Paul.


                  __________________________________________________
                  Do You Yahoo!?
                  Get personalized email addresses from Yahoo! Mail - only $35
                  a year!  http://personal.mail.yahoo.com/


                  To unsubscribe from this group, send an email to:
                  soaplite-unsubscribe@yahoogroups.com


                • Paul Kulchenko
                  Hi, Ray! ... Agree. Fixed list: OK Transport + OK SOAP 1. 200 OK + SOAP message (normal result) Error Transport + no SOAP 2a. 500 Server Error + error message
                  Message 8 of 9 , Feb 14, 2001
                  • 0 Attachment
                    Hi, Ray!

                    --- Ray Rizzuto <ray.rizzuto@...> wrote:
                    > In your list of errors, I don't see the case I'm experiencing,
                    > which is a timeout:
                    >
                    > 500 Can't connect to pc-rizzuto-p:9999 (Timeout)
                    Agree. Fixed list:

                    OK Transport + OK SOAP
                    1. 200 OK + SOAP message (normal result)

                    Error Transport + no SOAP
                    2a. 500 Server Error + error message (not SOAP)
                    2b. 400 Bad Method + error message (not SOAP)
                    2c. 510 Not Extended + error message (not SOAP)
                    2d. All other errors

                    Error Transport + Fault SOAP
                    3a. 500 Server Error + SOAP message (Fault result)
                    3b. 400 Bad Method + SOAP message (Fault result)

                    OK transport + Fault SOAP
                    4. 200 OK + SOAP message (Fault result)

                    > In that case, what should I get as the second parameter to the
                    > fault
                    > handler? In the debugger, @_ has length 2, and print $_[1], but
                    > print ref
                    > $_[1] returns an empty string. Is that because the content of the
                    > response is empty?
                    Exactly. ref $_[1] will return empty string even if $_[1] is not
                    empty, but doesn't represent any referense and contains plain string,
                    like 'abc'. That means that content of message either empty or not
                    parsed.

                    Best wishes, Paul.


                    __________________________________________________
                    Do You Yahoo!?
                    Get personalized email addresses from Yahoo! Mail - only $35
                    a year! http://personal.mail.yahoo.com/
                  • Ray Rizzuto
                    Paul, I had a minor typo. In a timeout situation, in the fault handler: print $_[1] prints an empty string print defined $_[1] prints 1 print ref $_[1]
                    Message 9 of 9 , Feb 14, 2001
                    • 0 Attachment
                      Paul,
                       
                      I had a minor typo.  In a timeout situation, in the fault handler:
                       
                      print $_[1] prints an empty string
                      print defined $_[1]  prints 1
                      print ref $_[1]  prints an empty string
                       
                      Since this is a transport error $_[1] is string, which is why ref $_[1] is empty.  Since the content of the returned message is empty in the case of a timeout, that explains why $_[1] is also an empty string.
                       
                      Ray
                      -----Original Message-----
                      From: Paul Kulchenko [mailto:paulclinger@...]
                      Sent: Wednesday, February 14, 2001 4:16 PM
                      To: soaplite@yahoogroups.com
                      Subject: RE: [soaplite] Re: on_fault

                      Hi, Ray!

                      --- Ray Rizzuto <ray.rizzuto@...> wrote:
                      > In your list of errors, I don't see the case I'm experiencing,
                      > which is a timeout:
                      >
                      > 500 Can't connect to pc-rizzuto-p:9999 (Timeout)
                      Agree. Fixed list:

                      OK Transport + OK SOAP
                      1. 200 OK + SOAP message (normal result)

                      Error Transport + no SOAP
                      2a. 500 Server Error + error message (not SOAP)
                      2b. 400 Bad Method + error message (not SOAP)
                      2c. 510 Not Extended + error message (not SOAP)
                      2d. All other errors

                      Error Transport + Fault SOAP
                      3a. 500 Server Error + SOAP message (Fault result)
                      3b. 400 Bad Method + SOAP message (Fault result)

                      OK transport + Fault SOAP
                      4. 200 OK + SOAP message (Fault result)

                      > In that case, what should I get as the second parameter to the
                      > fault
                      > handler?  In the debugger, @_ has length 2, and print $_[1], but
                      > print ref
                      > $_[1] returns an empty string.  Is that because the content of the
                      > response is empty?
                      Exactly. ref $_[1] will return empty string even if $_[1] is not
                      empty, but doesn't represent any referense and contains plain string,
                      like 'abc'. That means that content of message either empty or not
                      parsed.

                      Best wishes, Paul.


                      __________________________________________________
                      Do You Yahoo!?
                      Get personalized email addresses from Yahoo! Mail - only $35
                      a year!  http://personal.mail.yahoo.com/


                      To unsubscribe from this group, send an email to:
                      soaplite-unsubscribe@yahoogroups.com


                    Your message has been successfully submitted and would be delivered to recipients shortly.