MessageHandlers and SOAP faults

[Brent Putman]

On 6/12/15 7:13 PM, Cantor, Scott wrote:
> 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).

I wouldn't have thought that was important in the proposed scenario
where the whole Fault is supplied.  What's the reason or use case for
*not* wanting to send the FaultString (much less the Detail) if that's
what the Fault emitter wanted?  I guess AddSOAPFault could remove the
FaultString if detailedErrors=false, but I'm not seeing why it should.


> Well, looking at that specific example, this is probably one reason I was very uncomfortable with the whole thing. In a scenario with SOAP, you might have a lot of actions that are assuming they're operating on an Envelope as the outbound message type. 

Well, actually, not really.  They should really never do that, same for
the MessageHandlers. In handlers and actions, the SOAP Envelope should
always be accessed through (for SOAP 1.1) the SOAP11Context.  That
works regardless of whether you're doing "payload oriented" messaging
(where the message is SAMLObject or whatever) or "transport-oriented"
(where the message is Envelope). The main purpose of that context is to
abstract away the difference. 

I mean, you *could* have a set of Actions, MessageHandlers and
MessageEncoders that strictly assume transport messaging and that the
message is Envelope.  But those would be of limited usefulness.  It's
better to make them work with both styles, IMHO.


> But in the fault action, it has to be able to set a Fault as the outbound type. I'm not sure you can hang together a system that suddenly changes the generic types in the PRC from one to the other without it being very suspicious looking, even though at runtime it obviously doesn't even care.

Yes, that is actually the other problem I see with the AddSOAPFault
approach, hence my initial comments about the generics.  The way I
always envisioned SOAP fault handling to work (or any error handling
pipeline where the error message type wasn't the same as the "regular"
message type) was via a dedicated outbound pipeline.  That was the
point behind the stuff I put into messaging-api, package
org.opensaml.messaging.error.

If your main flow is modeled as e.g.
ProfileRequestContext<SAMLObject,SAMLObject>, then obviously you can't
put a Fault as the outbound message. There must therefore be another
mechanism for branching to an outbound error pipeline. 


>
> There's probably a similar example with ECP because I think it actually puts the Response into the outbound slot because it can have the encoder create the Envelope, but when an exception occurs, it will sometimes have to end up sending out a Fault.

Yeah, I had already thought about this general issue.  That's the
org.opensaml.messaging.error stuff.  I haven't looked at the ECP stuff,
but was going to.

Fwiw, there is a similar issue I had to deal with in the SOAP client on
receiving back a Fault response.  Actually the issue is really in the
HttpClient HttpResponse MessageDecoder impl. You can't just return the
Fault in the MessageContext as the getMessage() for exactly these same
reasons.  So you don't.  The decoder throws a MessageDecodingException
specialization that carries the fault, which is then caught by the
client and re-thrown as a SOAPFaultException.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150612/d0504742/attachment.html>