[
https://issues.apache.org/jira/browse/CXF-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin resolved CXF-5387.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.7.8
3.0.0-milestone2
> 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
> Fix For: 3.0.0-milestone2, 2.7.8
>
>
> 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)
