[
https://issues.apache.org/jira/browse/CXF-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin updated CXF-5387:
---------------------------------
Description:
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 using Provider<>
API process requests from different clients with any SOAPAction.
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.
was:
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.
The problem is that there are some scenarios where the proxies using Provider<>
API process requests from different clients with any SOAPAction.
There are two ways to fix the problem:
1. Introduce option "allowWrongSOAPAction" and tolerate wrong action only if a)
action is not specified in service model and b) flag is set
2. If action is not specified in ServiceModel, accept all SOAPAction (not only
empty ones)
Personally I prefer option (2), because current behavior is not intuitive:
in case of using proxy implementing Provider<> API: even if SOAP action has
reasonable value created by SoapUI (wsdl target namespace/operation name), CXF
responses with error "The given SOAPAction XXX does not match an operation",
because OperationInfo has empty action value, that doesn't match to request
soap action
> Relax SOAPAction check in SoapActionInInterceptor
> -------------------------------------------------
>
> Key: CXF-5387
> URL: https://issues.apache.org/jira/browse/CXF-5387
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
> Affects Versions: 2.7.7
> Reporter: Andrei Shakirin
> Assignee: Andrei Shakirin
>
> 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 using
> Provider<> API process requests from different clients with any SOAPAction.
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
