RE: Use of FaultTo when propagating WS-A Faults

Nothing prevents a sender from constructing a message without ws-a
headers.  Or from not sending a message at all if it knows the result
will just be an error (client-side ws-a properties incomplete + ws-a
headers required by server = doomed message = don't bother).  I don't
think saying anything in our spec would change that fact.

 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Vikas
Deolaliker
Sent: Sunday, July 17, 2005 3:02 PM
To: 'Rogers, Tony'; 'David Hull'; 'David Orchard'
Cc: public-ws-addressing@w3.org
Subject: 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