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

RE: [soaplite] HTTP Errors

Expand Messages
  • Michael Percy
    Paul, I figured it out... I should have been using the on_fault handler... it is right there in the docs. I thought I was covered from doing a check after the
    Message 1 of 3 , Apr 17 6:58 PM
    • 0 Attachment
      Paul,
      I figured it out... I should have been using the on_fault handler... it is
      right there in the docs. I thought I was covered from doing a check after
      the method call but I guess not. Sorry to bother you.

      Thanks,
      Mike

      > -----Original Message-----
      > From: Michael Percy [mailto:mpercy@...]
      > Sent: Tuesday, April 17, 2001 6:51 PM
      > To: 'soaplite@yahoogroups.com'
      > Subject: [soaplite] HTTP Errors
      >
      >
      > Hi Paul,
      > I am developing an application on top of SOAP::Lite which of
      > course relies
      > on the fault method to know if anything obvious went wrong with the
      > transaction. However, I cannot always count on a SOAP server
      > being up and
      > running at the location I am using for the proxy.
      >
      > For some reason, I am not getting the following HTTP errors
      > in any kind of
      > fault structure:
      > 404 Not Found (File does not exist in Apache DocumentRoot)
      > 405 Method Not Allowed (Apache disallowed the POST method)
      > 500 Can't connect (nothing listening on the port)
      >
      > Why are these error first being spewed onto STDERR and then killing my
      > process, instead of being put into a fault method? Shouldn't they be
      > propogated back to the client in this form, or am I confused?
      > If I am just
      > confused, how can I detect/handle this situation? I am using
      > SOAP::Lite 0.46
      > with a forking SOAP::Transport::HTTP::Daemon as my server and
      > SOAP::Lite as
      > my client.
      >
      > Here is an example of output I am getting:
      > SOAP call failed: 500 Can't connect to bacardi:808 (Timeout),
      > <STDIN> line 5.
      > at /export/home/mpercy/source/lib/Access.pm line 98
      >
      > All line 98 is is this:
      > my $res = $soap->call($method, @args);
      >
      > Any help you could lend would be greatly appreciated.
      >
      > Thanks,
      > Mike
      >
      > ------------------------ Yahoo! Groups Sponsor
      > ---------------------~-~>
      > Secure your servers with 128-bit SSL encryption!
      > Grab your copy of VeriSign's FREE Guide,
      > "Securing Your Web site for Business." Get it now!
      > http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/WNqXlB/TM
      > --------------------------------------------------------------
      > -------_->
      >
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Paul Kulchenko
      Hi, Michael! ... Unfortunately not only. It may depend on Server implementation also, though I tried hard to hide these details from you. Several situations
      Message 2 of 3 , Apr 17 7:26 PM
      • 0 Attachment
        Hi, Michael!

        Right. Here is (long) post that explains it with more details:

        --- 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)

        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)

        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.

        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).

        Best wishes, Paul.

        --- Michael Percy <mpercy@...> wrote:
        > Paul,
        > I figured it out... I should have been using the on_fault
        > handler... it is
        > right there in the docs. I thought I was covered from doing a check
        > after
        > the method call but I guess not. Sorry to bother you.
        >
        > Thanks,
        > Mike
        >
        > > -----Original Message-----
        > > From: Michael Percy [mailto:mpercy@...]
        > > Sent: Tuesday, April 17, 2001 6:51 PM
        > > To: 'soaplite@yahoogroups.com'
        > > Subject: [soaplite] HTTP Errors
        > >
        > >
        > > Hi Paul,
        > > I am developing an application on top of SOAP::Lite which of
        > > course relies
        > > on the fault method to know if anything obvious went wrong with
        > the
        > > transaction. However, I cannot always count on a SOAP server
        > > being up and
        > > running at the location I am using for the proxy.
        > >
        > > For some reason, I am not getting the following HTTP errors
        > > in any kind of
        > > fault structure:
        > > 404 Not Found (File does not exist in Apache DocumentRoot)
        > > 405 Method Not Allowed (Apache disallowed the POST method)
        > > 500 Can't connect (nothing listening on the port)
        > >
        > > Why are these error first being spewed onto STDERR and then
        > killing my
        > > process, instead of being put into a fault method? Shouldn't they
        > be
        > > propogated back to the client in this form, or am I confused?
        > > If I am just
        > > confused, how can I detect/handle this situation? I am using
        > > SOAP::Lite 0.46
        > > with a forking SOAP::Transport::HTTP::Daemon as my server and
        > > SOAP::Lite as
        > > my client.
        > >
        > > Here is an example of output I am getting:
        > > SOAP call failed: 500 Can't connect to bacardi:808 (Timeout),
        > > <STDIN> line 5.
        > > at /export/home/mpercy/source/lib/Access.pm line 98
        > >
        > > All line 98 is is this:
        > > my $res = $soap->call($method, @args);
        > >
        > > Any help you could lend would be greatly appreciated.
        > >
        > > Thanks,
        > > Mike
        > >
        > > ------------------------ Yahoo! Groups Sponsor
        > > ---------------------~-~>
        > > Secure your servers with 128-bit SSL encryption!
        > > Grab your copy of VeriSign's FREE Guide,
        > > "Securing Your Web site for Business." Get it now!
        > > http://us.click.yahoo.com/KVNB7A/e.WCAA/bT0EAA/WNqXlB/TM
        > > --------------------------------------------------------------
        > > -------_->
        > >
        > > To unsubscribe from this group, send an email to:
        > > soaplite-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to
        > http://docs.yahoo.com/info/terms/
        >
        >


        __________________________________________________
        Do You Yahoo!?
        Yahoo! Auctions - buy the things you want at great prices
        http://auctions.yahoo.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.