I have a bit regression under 2.7.7 because of changes in SoapActionInInterceptor (https://fisheye6.atlassian.com/changelog/cxf?cs=1368559 )
SoapActionInInterceptor requires that the SOAPAction exactly matches to the service operation.
This is correct accordingly WSI-Basic profile 1.2 spec:
"R2745 When the wsa:Action header is absent from an ENVELOPE, an HTTP Request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted empty string value if, in the corresponding WSDL description, the soapAction attribute of the wsoap11:operation is either not present, or present with an empty string as its value."
The problem is that there are some scenarios where the proxies or gateways (implementing Provider<> API) should process requests from different clients with any SOAPAction. These scenarios cannot be supported currently.
Also WS-I Basic profile 2.0 relaxes SOAPAction requirement:
"R2744 If the action parameter on the HTTP Content-Type header is present in a MESSAGE, its value MUST be equal to the value of the soapAction attribute of the corresponding wsoap12:operation in the WSDL description, if this attribute is present and not empty."
Unlike SOAP 1.1, SOAP 1.2 HTTP binding does not use the SOAPAction HTTP header in the HTTP Request messages. Relying on the presence of SOAPAction HTTP header or the value of SOAPAction HTTP header may result in interoperability problems.
R2760 A RECEIVER MUST NOT rely on the presence of SOAPAction HTTP header to correctly process the message.
R2761 A SENDER SHOULD NOT include the SOAPAction HTTP header.
I see two things that can be improved in current implementation:
1. For SOAP 1.1: introduce option "allowNonMatchingToDefaultSoapAction" and tolerate wrong action only if a) action is not specified in service model and b) flag is set
2. For SOAP 1.2: relax control for SOAP 1.2 if SOAPAction is not defined in service model.