<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 6/12/15 7:13 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:2EFD99EF-0BF2-4427-9190-F35A52AFA1B8@osu.edu"

      type="cite">

      <pre wrap="">On 6/12/15, 5:59 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">

In short, it seems to me that the SOAP processing component is the thing that ought to build the Fault, since

that's where all the info is.

</pre>

      </blockquote>

      <pre wrap="">

I guess I buy that, though I would note that there's still a need to make sure we can switch on and off detailed errors (which are off by default).

</pre>

    </blockquote>

    <br>

    Starting at this again, I don't know why I in the past didn't see

    the somewhat obvious solution to SOAP fault handling approach: the

    SOAP encoder already has to be aware of Faults, since it has to send

    a 500 in that case.  Since Fault is a binding/transport-specific way

    of reporting an error, it seems in hindsight (to me at least) that

    the encoder ought to be totally Fault-aware, and take care of

    emitting the Fault if one is registered.<br>

    <br>

    I just added the context and helper support for the Fault in the

    SOAP11Context.  And using that, I added the (pretty minimal) update

    to the HTTPSOAP11Encoder to make it check for the presence of a

    Fault, and emit that instead of the payload.<br>

    <br>

    This allows messaging-only code to have a complete solution for

    Fault handling, entirely native to the messaging API.<br>

    <br>

    And on the AddSOAPFault ProfileAction:  In addition to my earlier

    suggestion that it check for the presence of an outbound Fault

    already registered per the above, it should probably "emit" any

    Fault it builds (by Event mapping, etc) using the same mechanism,

    rather than (unnaturally) sticking it into the MessageContext

    getMessage().<br>

    <br>

    I think this is a much cleaner and consistent solution.  Do you have

    any objections to that?  I think it should be a completely internal

    change.<br>

  </body>

</html>