Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Duplicate
-
Affects Version/s: 4.0.4
-
Fix Version/s: 4.1
-
Component/s: None
-
Security Level: Public
-
- Description:
-
Hide
When the service is on document mode, the component receiving a soap envelop must:
1-search the soap action into the payload
2a-if it's found, it must search the operation with the soap action matching the soap action of the payload
2b-if it's not found, or the wsdl haven't this soap action, the root element must be used to search the operation with the content ("message" on wsdl 1.x) matching (name attribute).Today, the soapAction is always used:
// Retrieve message operation and service
final String soapAction = inContext.getWSAAction(); -->This get retrieve the string ""
[...]
if (soapAction != null ) { -->always true! bindingOperation = WsdlHelper.findOperationUsingSoapAction(soapAction, desc); }We often see binding operation with an empty soap action (I don't know why, it's not a mandatory attribute. It's maybe because the WS-I samples have got its soapAction=""). So, in this case (that is my case of course), the bc-soap always choose...the first operation.
I think it's itsself a minor bug: we can remove the soapAction="" into the wsdl. But sometimes, we're not allowed to change the wsdl: so it's a major bug for me
.ShowWhen the service is on document mode, the component receiving a soap envelop must: 1-search the soap action into the payload 2a-if it's found, it must search the operation with the soap action matching the soap action of the payload 2b-if it's not found, or the wsdl haven't this soap action, the root element must be used to search the operation with the content ("message" on wsdl 1.x) matching (name attribute). Today, the soapAction is always used: // Retrieve message operation and service final String soapAction = inContext.getWSAAction(); -->This get retrieve the string "" [...] if (soapAction != null ) { -->always true! bindingOperation = WsdlHelper.findOperationUsingSoapAction(soapAction, desc); } We often see binding operation with an empty soap action (I don't know why, it's not a mandatory attribute. It's maybe because the WS-I samples have got its soapAction=""). So, in this case (that is my case of course), the bc-soap always choose...the first operation. I think it's itsself a minor bug: we can remove the soapAction="" into the wsdl. But sometimes, we're not allowed to change the wsdl: so it's a major bug for me.
-
- Environment:
- RHEL5, esb 3.1.1
Issue Links
| Duplicate | |||
|---|---|---|---|
|
|||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | getCustomer.zip [ 10448 ] | |
| Priority | Major [ 3 ] |
| Link |
This issue duplicates |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Comment |
[ In the chapter 4.7.25 Describing SOAPAction of the basic profile http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html, it is indicated:
"Interoperability testing has demonstrated that requiring the SOAPAction HTTP header field-value to be quoted increases interoperability of implementations. Even though HTTP allows for header field-values to be unquoted, some implementations require that the value be quoted. The SOAPAction header is purely a hint to processors. All vital information regarding the intent of a message is carried in the envelope. R2744 A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description. R2745 A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted empty string value, if in the corresponding WSDL description, the soapAction of soapbind:operation is either not present, or present with an empty string as its value." So a SOAPAction HTTP header must be present in the request and the SOAPAction HTTP header may be an empty string. (However I think it is possible not to have SOAPAction HTTP header if the WSA-Addressing is enabled - It does not work on the BC SOAP component) Currently, the version 4.0.4 of the BC SOAP component - gets the SOAP action from the HTTP header (the SOAP action can be an empty string) - retrieve the operation in the WSDL thanks to the SOAP action (it takes the first operation found in the WSDL even if finds several operations) - if it does not find an operation, it looks the first child of the SOAP body (for interoperability but it is not correct) the version 4.1-SNAPSHOT of the BC SOAP component - gets the SOAP action from the HTTP header (the SOAP action can be an empty string) - retrieve the operation in the WSDL thanks to the SOAP action (it does not take an operation if several operations are found) - if it does not find an operation and only one operation, it looks the first child of the SOAP body (for interoperability but it is not correct) ] |
| Fix Version/s | 4.1_4.0 [ 10269 ] | |
| Fix Version/s | 4.1 [ 10186 ] |
| Fix Version/s | 4.1 [ 10186 ] | |
| Fix Version/s | 4.1_4.0 [ 10269 ] |