Petals BC SOAP

Not valid Document wrapped attitude

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical 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 .

    Show
    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 .
  • Environment:
    RHEL5, esb 3.1.1
  1. getCustomer.zip
    (3 kB)
    Frédéric Gardes
    Fri, 19 Nov 2010 - 14:19:36 +0100

Issue Links

Activity

Hide
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 15:17:46 +0100

Wrong.Read the extract into this Jira, or test with the wsdl provided or test with any document multi operations wsdl, and you will see that you always "find" an operation : the first of the wsdl.

Show
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 15:17:46 +0100 Wrong.Read the extract into this Jira, or test with the wsdl provided or test with any document multi operations wsdl, and you will see that you always "find" an operation : the first of the wsdl.
Hide
noddoux added a comment - Fri, 19 Nov 2010 - 15:15:14 +0100

There is no difference between an empty SOAP action or no SOAP action in the WSDL (cf R2745 in the basic profile)

Show
noddoux added a comment - Fri, 19 Nov 2010 - 15:15:14 +0100 There is no difference between an empty SOAP action or no SOAP action in the WSDL (cf R2745 in the basic profile)
Hide
noddoux added a comment - Fri, 19 Nov 2010 - 15:12:31 +0100 - edited

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)

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)
Show
noddoux added a comment - Fri, 19 Nov 2010 - 15:12:31 +0100 - edited 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)
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)
Hide
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:52:00 +0100

I did a mistake: if we remove into the wsdl the soapAction=""...it doesn't work too
The code:

if (op.getSoapAction() != null && op.getSoapAction().equals(soapAction)) {-->always true because op.getSoapAction() send ""
					res = op;
					find = true;
					break;
				}

So today, we can't use this bc-soap for a service:
->in document mode
->with at least 2 operations
->without put into the header soap the soapAction.
It's at least 30% of the current deployed services on the web. For me, it's a critical bug, and the 4.0.4 version must not be used. I go back to 4.0.3.

Show
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:52:00 +0100 I did a mistake: if we remove into the wsdl the soapAction=""...it doesn't work too The code:
if (op.getSoapAction() != null && op.getSoapAction().equals(soapAction)) {-->always true because op.getSoapAction() send ""
					res = op;
					find = true;
					break;
				}
So today, we can't use this bc-soap for a service: ->in document mode ->with at least 2 operations ->without put into the header soap the soapAction. It's at least 30% of the current deployed services on the web. For me, it's a critical bug, and the 4.0.4 version must not be used. I go back to 4.0.3.
Hide
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:20:45 +0100

The solution: you must chage:
if (soapAction != null )
by
if (soapAction != null && !soapAction.isEmpty())

Previously, a StringHelper into the cdk 5.1 was used: this is the core regression cause for me.

Show
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:20:45 +0100 The solution: you must chage: if (soapAction != null ) by if (soapAction != null && !soapAction.isEmpty()) Previously, a StringHelper into the cdk 5.1 was used: this is the core regression cause for me.
Hide
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:19:36 +0100

A wsdl sample, Axis 1/2, cxf 2.x, WS-I and IOSW valid.
Put it into a soap su consumes, invoke any operation (with SOAP UI for example), and you always will have the first operation response: getInfo here.

Show
Frédéric Gardes added a comment - Fri, 19 Nov 2010 - 14:19:36 +0100 A wsdl sample, Axis 1/2, cxf 2.x, WS-I and IOSW valid. Put it into a soap su consumes, invoke any operation (with SOAP UI for example), and you always will have the first operation response: getInfo here.

People

Dates

  • Created:
    Fri, 19 Nov 2010 - 14:14:50 +0100
    Updated:
    Thu, 16 Feb 2012 - 17:06:32 +0100
    Resolved:
    Fri, 19 Nov 2010 - 15:11:58 +0100