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: Tue, 13 Oct 2009 23:39:02 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1MxqxK-00046v-3Q@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7911


Doug Davis <dug@us.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dug@us.ibm.com




--- Comment #2 from Doug Davis <dug@us.ibm.com>  2009-10-13 23:39:01 ---
This issue is an interesting one.  While it starts out talking about
the wsa:Action and the Body wrapper, technically this issue can be
more abstractly talked about - by that I mean, what does a server
do when it gets a message that doesn't comply with the spec/doc
that defines that message?  And this isn't just about the action vs
body.  Any of the requirements (MUSTs) in the spec would fall into 
this category.  

For example, what if a client sends:
wsa:Action=http://www.w3.org/2009/09/ws-evt/Subscribe
Body=<wse:Subscribe/>

this violates the spec because it doesn't adhere to the schema.
Each and every requirement in our specs falls under the scope of
this issue.

SOAP already defines a Sender fault, where it says its used for 
cases where: "The message was incorrectly formed or did not contain the
appropriate information in order to succeed. "

I'm wondering what more we could do in our specs.  Even if we did
add some text saying that this fault MUST be generated, it feels a bit
like a recursive situation because we're already dealing with a non-compliant
implementation, so will it really do any good to add more MUSTs to the spec
that will probably just be ignored as well?

Has anyone has really seen this as a problem in any of the
implementations or interop testing that's been done.  People will detect
whatever bad stuff there is a message and deal with it as they want.  If 
they can perform some kind of error recovery then they will and move on.
If they can't then they'll generate a fault - which fault will probably
be up to them.  Given that the sender is already not compliant with the
spec, remember we're not talking about the simple case of them providing
a value that is out of range - we're talking about something that is 
so fundamentally wrong (like not adhering to the entire shape of the
message), that any kind of automatic error recovery is doubtful.
Odds are it'll require some coding change to fix this.  So having an
interoperable/well-defined fault (which is typically useful so that 
automagic error recovery can be attempted) is not really going to help any.


-- 
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 Tuesday, 13 October 2009 23:39:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 October 2009 23:39:08 GMT