RE: Use of FaultTo when propagating WS-A Faults

If we have this binary switch testing presence/absence of wsa:action, then
can we assume that source or senders of a message may decide to not create a
SOAP message for delivery in the first place sparing the receivers and
intermediaries from run-time overhead required to process a faulty SOAP
message? 

 

For example, at the source node, when creating a soap message using wsa, at
the point of binding to an underlying transport, if the ws-a block does not
contain the action, then the source node will not include any wsa headers in
the soap message. 


Vikas

 

 

  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
Sent: Friday, July 15, 2005 12:27 PM
To: David Hull; David Orchard
Cc: public-ws-addressing@w3.org
Subject: RE: Use of FaultTo when propagating WS-A Faults

 

I am becoming increasingly concerned about this idea of using someof the
WS-A headers even when the message is faulty in WS-A terms.

 

If we follow Dave Hull's described situation, then we have the ingredients
for a nasty DDoS scenario - send out a stack of messages to a range of
servers, all of them with FaultTo pointing to the target machine, and no
Action - the target machine will be bombarded with Fault messages. Not a
good thing.

 

I prefer the idea of a binary switch - we are using WS-A or we are not using
WS-A - if the message is WS-A faulty (eg: no Action) then we are NOT using
WS-A, so we should not be using the FaultTo address. We fault using the
back-channel (if there is one), or we drop the message in the bit-bucket
(possibly logging it). Note that the back-channel may be the HTTP return
channel, or some other understood back-channel as defined by the server's
circumstances.

 

I think of this as being similar to the situation we discussed in the Async
group in Palo Alto - we have not yet accepted the WS-A headers, so we are
not in the position of being prepared to use them.

 

Fair enough?

 

Tony

-----Original Message----- 
From: public-ws-addressing-request@w3.org on behalf of David Hull 
Sent: Sat 16-Jul-05 4:28 
To: David Orchard 
Cc: public-ws-addressing@w3.org 
Subject: Re: Use of FaultTo when propagating WS-A Faults

What if we really are in a one-way scenario and "anonymous" is undefined?
It seems wrong not to try to send a fault to the [fault endpoint] if it
exists.  It seems particularly wrong simply to drop such a message on the
floor because it happened to lack an [action].

David Orchard wrote: 

Related to LC76, we came to the agreement that ReplyTo would NOT be used
when a message contains an imperfect set of WS-A Headers, like a missing
WS-A: Action.

 

What about the use of FaultTo for a Fault?  Imagine the scenario where
FaultTo is non-anonymous and Action is missing.  The receiver decides to
Fault (perhaps because mU was on a WS-A header).  

 

I think the correct behaviour is that the FaultTo should not be used for
propagating the Fault, because the FaultTo is part of the overall WS-A set
of headers which aren't valid.  But that does seem a little
counter-intuitive.

 

If the FaultTo is ignored, then Fault would probably be sent back over an
HTTP Connection if one exists.  This is like changing the faultTo to become
anonymous.  This seems to be yet another scenario where even though the
sender believes it is a one-way message, it will allow for a soap fault in
the response if it wants as much information as possible.

 

Cheers,

Dave