This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
What happens if a message contains a ws-tra:Get action and a ws-tra:Put wrapper (or more generally any 'foo' action with a non matching 'bar' wrapper). As we are duplicating the information between the wrapper and the action, we need to have a good story when they don't match to avoid different behaviours depending on implementation choice.
generate a "fubar" sender fault?
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.
Dug, it's bit different than that. The main issue is that we are defining two ways that must be synched to advertise the action, instead of one, because of the need to be BP compliant. While I entirely agree that we will not boil the ocean and try to define all possible errors and associated faults, we have to define what happens when something bad happens because we defined the same thing in two different places. Bob, yes a "I'm afraid I can't do that, Dave" sender fault MUST be sent if action and wrapper are not matching is what I have in mind.
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()? 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. 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.
(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 >>
> 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. No we have not. The spec is very clear that this MUST NOT happen. If it does the sender has not adhered to the spec. This is no different than the following other uses of MUST (just a random sampling): - - - - - - - - - - - - - All messages defined by this specification MUST be sent to a Web service that is addressable by an EPR (see [WS-Addressing]). Unless otherwise noted, all IRIs are absolute IRIs and IRI comparison MUST be performed according to [RFC 3987] section 5.3.1. A compliant SOAP Node that implements a resource MUST provide the Get operation as defined in this specification, and MAY provide the Put and Delete operations. A Get request MUST be targeted at the resource whose representation is desired as described in 2 Terminology and Notation of this specification. - - - - - - - - - - - - - In each of these cases we don't say what MUST happen if the MUST is not adhered to. I would point out that this is true for lots of other specs (not just WS* specs), for example some from the HTTP spec: - - - - - - - - - - - - - HTTP/1.1 recipients MUST accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. These special characters MUST be in a quoted string to be used within a parameter value (as defined in Section 3.3). The proxy/gateway's response to that request MUST be in the same major version as the request. - - - - - - - - - - - - - In none of these cases does the spec say what is to happen if the MUST is not adhered to. > See above, we introduced a new class of error. huh? How? The spec says what the XML on the wire MUST look like. This is no different than requiring the client to adhere to the xsd defined by a spec. I feel like there's something else behind this issue and I'm still not seeing it - or you're not letting us in on the secret. If you really want to head down this rat hole, then we need to do this for ALL MUSTs in ALL RA specs and not just cherry-pick one. And where do you draw the line? Once you say what MUST happen during this faulting condition you've now introduce yet another MUST and how will you recover from that one? Its going to be recursive. My objection to this isn't just because it seems like a pointless exercise, but one of a practical nature. The path you're headed down is one where you're going to require all endpoints to be compliance checkers. They can no longer be forgiving in what they accept - they MUST verify all incoming messages and they MUST reject them if they don't adhere to the spec in the slightest way. This is a very dangerous and expensive path to head down. Imagine if all HTTP servers rejected ALL HTTP requests that were not 100% perfect. What percentage of the clients would suddenly stop working? I suspect a lot of them. Many people design their systems under the "be liberal in what you accept" model - this issue will ban this.
proposal from 2009-01-06 f2f minutes "{some combo of specs} allows receivers to dispatch on either the [Action] property or the QName of the [Body] child. Implementations that authorize requests based on the requested operation are advised to ensure that the property values used for such authorization decisions are consistent with the property values that are used for dispatching."
A new version of the text - making it a bit more generic: The Basic Profile defines an operation signature as a comination of the [Action] property and the QName of the [Body] child. An implementation that examines just one of those values, but at multiple points during the entire processing of the message, are advised to ensure that the values that are used each time are consistent.
Ram's comments and an alternate proposal is at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0077.html
Resolved to close with no action on 2009-12-01