On Sep 11, 2012, at 9:17 AM, "Mathews, Christopher" <[email protected]> wrote:
> Since upgrading from CXF 2.6.1 to CXF 2.6.2 we are getting reports from a few > of our clients that they are receiving errors calling our services. In > particular, a small number of client appear to be receiving a SOAP Fault with > the error: "The given SOAPAction XXX does not match an operation.". Our > wsdls define their soapAction to be empty string and as far as I understand > it that should instruct toolkits to not send a SOAPAction header. Well, either not send it or send: SOAPAction: "" CXF will do the latter. > There is a well-known issue with older versions of Axis2 clients (which we > hit): https://issues.apache.org/jira/browse/AXIS2-4264. However, even > ignoring the AXIS2 we have at least one other client explicitly setting the > SOAPAction header and receiving an error on calls that previous to our > upgrade to CXF 2.6.2 worked fine. > > I looked for more detail on this change but I couldn't find a specific JIRA > issue for the CXF 2.6.2 release that seemed to match with this behavior, There is an upcoming CVE that will cover the reasoning for the change. Colm is on vacation this week, but likely shortly after he gets back he'll get the CVE uploaded to: http://cxf.apache.org/security-advisories.html and announcement sent out. Keep an eye out. > so I am hoping maybe someone here could provide some input on how to properly > handle this. I have put in a change to handle the AXIS2 client issue in our > application before it hits CXF (via a Servlet Filter) but it feels like I am > hacking around an issue that maybe I don't fully understand... and when we > hit the second client issue that definitely reinforced the feeling. It > always feel a little strange going back to a client and telling them their > code is broken when it worked perfectly fine a month ago and they haven't > made any changes since. Is it appropriate for CXF to be rejecting these > requests? Yes. CXF should have been rejecting these requests all along. It was a bug that it wasn't. > Any way to override this behavior or is the correct answer to work with the > clients to force in the changes (however painful that ends up being)? You CAN write an interceptor that is stuck on the chain that would do something like: Map<String, List<String>> headers = CastUtils.cast((Map<?, ?>)message.get(Message.PROTOCOL_HEADERS)); headers.remove("SOAPAction"); and similar removal of the action for SOAP 1.2 if needed. If the SOAPAction is not there (it is optional), then we cannot check it. However, it might be better to, instead of removing it, check if it's one of the "known broken" client actions and set it to "\"\"" in those specific cases. Thus, future clients won't be able to send invalid requests. > FYI... there is a stackoverflow question here that looks to be hitting the > same issue so I am hoping the problem isn't isolated to me: > http://stackoverflow.com/questions/12220851/the-given-soapaction-does-not-match-an-operation Answered there. Thanks for the pointer. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
