Soap action string mismatch does not prevent web service method from running.
-----------------------------------------------------------------------------
Key: AXIS2-2798
URL: https://issues.apache.org/jira/browse/AXIS2-2798
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Affects Versions: 1.2
Environment: Windows XP Pro, Tomcat 5.0.28, Axis2 1.2
Reporter: David R. Kraus
Fix For: 1.2
I have an old client which sends the following SOAP action:
http://company.com/webservices/GetInfo
However the new receiving service expects a different SOAP action:
http://company.com/webservices/v2/GetInfo
The idea is that when a service becomes incompatible with previous clients, you
change the namespace to prevent older clients from accessing. So, we added a
version number to the webservice namespace, and to all SOAP actions, to control
access.
However, I discovered that the Axis2 (1.2) service actually accepted the
GetInfo action/call and performed the operation, even though the version number
was missing from the SOAP action string. When I traced through Axis2 code I saw
that the SOAP action mismatch was detected, but that the service code was able
to match the operation name GetInfo by comparing the SOAP action suffix
"GetInfo" to the operation GetInfo, and so proceeded with handling it.
Anyway, is this a configurable behavior? Should this be happening?
I did some tracing through Axis2 code and this is what I saw:
1. SOAPActionBasedDispatcher.findOperation can't find /GetInfo
2. AddressingBasedDispathcer.findOperation can't find /GetInfo
3. SOAPMessageBodyBasedDispatcher.findOperation is able to find GetInfo and
processing continues successfully.
Below is SOAPMessageBodyBasedDispatcher.findOperation. See comment added to
source...
public AxisOperation findOperation(AxisService service, MessageContext
messageContext)
throws AxisFault {
OMElement bodyFirstChild =
messageContext.getEnvelope().getBody().getFirstElement();
AxisOperation axisOperation = null;
if (bodyFirstChild != null){
axisOperation =
service.getOperationByMessageElementQName(bodyFirstChild.getQName());
// this is required for services uses the RPC message receiver
if (axisOperation == null){
QName operationName = new QName(bodyFirstChild.getLocalName());
axisOperation = service.getOperation(operationName);//****This
is where the axisOperation is finally found successfully.****
}
}
return axisOperation;
}
My interpretation of the behavior was that Axis2 was able to find the operation
GetInfo, so it continued, even thought the initial soap action string was not
matched. When I tried an example of a soap action where the soap action suffix
did not match the operation name in the WSDL, then failure occurred as
expected. So, if I had a soap action like
http://company.com/webservices/GetData2 which was associated with an operation
named GetData, then the soap action mismatch would occur as before, but
SOAPMessageBodyBasedDispatcher.findOperation could not match GetData2 with
GetData, so the request failed.
thanks, Dave
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
