MessageHandlers and SOAP faults

[Brent Putman]

On 6/12/15 7:13 PM, Cantor, Scott wrote:
> On 6/12/15, 5:59 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>> 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.
> 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).
>

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.

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.

This allows messaging-only code to have a complete solution for Fault
handling, entirely native to the messaging API.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150619/e74b6a7e/attachment.html>