W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > October 2009

[Bug 7911] mismatching action and body wrapper

From: <bugzilla@wiggum.w3.org>
Date: Mon, 19 Oct 2009 21:18:11 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1MzzcJ-0005iv-JY@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7911





--- Comment #5 from Yves Lafon <ylafon@w3.org>  2009-10-19 21:18:11 ---
(In reply to comment #4)
> But Yves, you're focusing on just one particular "mismatch" when there
> are any number of possible "mismatches".  What if the actionURI doesn't
> match what the spec says it should be? What if the schema of the body
> doesn't match the xsd in the wsdl?  What if the Dialect URI isn't
> a URI? What if the dateTime (in eventing) has had characters in it?
> What if the HTTP SOAPAction header doesn't match?  What if, in response
> to a T.Get() the server sends back a T.PutResponse()?

Our spec is not targeting those issues, but as I said before, we, in _this_
spec says "value A should be in places X and Y", so apart from the classical
error case where value is not really value A, or invalid, we have _introduced_
the case where X and Y can have different value.

Imagine that implementation Q checks only Action to dispatch, and Z checks only
the Wrapper name... If it happens that Q is a firewall and Z, behind a
firewall, execute the command without any further check, then you have a
security issue.

> You said:
> we have to define what happens when something bad happens because we 
> defined the same thing in two different places.
> 
> Why? What's special about "two different places"?  Does this imply
> we don't need to define what happens when something bad happens in 
> cases where we don't duplicate info?  I doubt it. 

See above, we introduced a new class of error.

> There are a ton of things that could be bad about the incoming 
> message and they seem to fall into the category of "you didn't do what the
> spec told you to do", because the spec is very clear about what is 
> supposed to be on the wire.  I'm missing why this one "mismatch" is special 
> and needs a new fault when the general soap Sender fault would seem
> to already cover it.

Well, I'm fine saying only "If the [Body] first child is not matching the
[Action] parameter for any defined Resource Operation, the recipient MUST
generate a SOAP Sender fault.", but it doesn't cost much to define a
wst:ActionAndWrapperMismatch sender fault like this:

<<
5.4 ActionAndWrapperMismatch                                                    

This fault is generated if the [Body] first child is not matching the           
[Action]                                                                        

[Code]    s:Sender                                                              
[Subcode] wst:ActionAndWrapperMismatch                                          
[Reason]  Action and Wrapper mismatch                                           
[Detail]  none      
>>


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
Received on Monday, 19 October 2009 21:18:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 19 October 2009 21:18:14 GMT