[
https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Yoshida updated CXF-3367:
-----------------------------
Description:
The inbound processing uses
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor to extract the
SOAPAction header from the protocol header and put it in the message's
property.The extraction code looks for the exact string "SOAPAction" in the
protocol header instead of looking for the soap action header in the
case-insenstive way.
The inbound processing initially converts the names of the transport headers
from the web container using HttpHeaderHelper. Later, the converted names are
stored in a plain map which is passed as the PROTOCOL_HEADERS property. So, if
the soap action header is provided as "SOAPAction" or "soapaction" from the web
container, this header is stored with key "SOAPAction" and it can be retrieved
later. However, if the name is provided using different mixed casing, it is
stored with that name and it can only be retrieved using this exact key.
Initially, I thought we could change SOAPActionInInterceptor locally to look
for the soapaction header. But this will not solve other potential problems
with the current map.
So, instead of just changing the SOAPActionInInterceptor, I am in favor of
changing the implementation of the PROTOCOL_HEADERS map to support the
case-insensitive lookup while preserving the original keys in the map.
Another reason favoring this approach is that the current case-sensitive map
can have a few other problems. For example, the map currently contains two
Content-Type headers after it is created by AbstractHTTPDestination (over
Jetty): one with "content-type" and the other with "Content-Type". And this is
confusing and may lead to some conflicts. Another problem is the extraction
problem for other headers when they are spelled in different mixed casing when
they are passed.
So, I think we should use a specific map class that matches the current
interface but supports the case-insensitive lookup while preserving the
original case sensitive keys. The attached ProtocolHeaders class satisfies this
requirement. Its unit test class ProtocolHeadersTest is also attached.
This class can be used in AbstractHTTPDestination to create the correct
protocol headers map. I added a test case AbstractHTTPDestinationTest to check
the extraction of the headers into the protocol headers map. The svn diff of
2.3.2 are attached.
Please take a look at the files and let me know how you think.
Thanks.
Regards, aki
was:
The inbound processing uses
org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor to extract the
SOAPAction header from the protocol header and put it in the message's
property.The extraction code looks for the exact string "SOAPAction" in the
protocol header instead of looking for the soap action header in the
case-insenstive way.
We need to replace the line
{code}
List<String> sa = headers.get(SoapBindingConstants.SOAP_ACTION);
{code}
with
{code}
List<String> sa = null;
// if we had the normalized names in the map, we could've picked the header
directly
for (Map.Entry<String, List<String>> header: headers.entrySet()) {
if (SoapBindingConstants.SOAP_ACTION.equalsIgnoreCase(header.getKey())) {
sa = header.getValue();
break;
}
}
{code}
Instead of this simple change, we could change JettyHTTPDestination so that the
protocol headers are stored with e.g., the lowercased header names. But this
change would require changes in several other places to keep the current
behavior in lookup and also in serialization unchanged (e.g., people using the
constants to do the lookup and this should work as long as the original headers
match the constants and for the outbound case, people expect the current mixed
case serializaiton). And I dont think this is feasible in 2.3.x.
Regards, Aki
Estimated Complexity: Moderate (was: Novice)
Remaining Estimate: 4h (was: 2h)
Original Estimate: 4h (was: 2h)
> SOAPAction value not extracted in the inbound processing if the header name
> does not match exactly "SOAPAction"
> ---------------------------------------------------------------------------------------------------------------
>
> Key: CXF-3367
> URL: https://issues.apache.org/jira/browse/CXF-3367
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.3.2
> Reporter: Aki Yoshida
> Fix For: 2.3.3
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The inbound processing uses
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor to extract
> the SOAPAction header from the protocol header and put it in the message's
> property.The extraction code looks for the exact string "SOAPAction" in the
> protocol header instead of looking for the soap action header in the
> case-insenstive way.
> The inbound processing initially converts the names of the transport headers
> from the web container using HttpHeaderHelper. Later, the converted names are
> stored in a plain map which is passed as the PROTOCOL_HEADERS property. So,
> if the soap action header is provided as "SOAPAction" or "soapaction" from
> the web container, this header is stored with key "SOAPAction" and it can be
> retrieved later. However, if the name is provided using different mixed
> casing, it is stored with that name and it can only be retrieved using this
> exact key.
> Initially, I thought we could change SOAPActionInInterceptor locally to look
> for the soapaction header. But this will not solve other potential problems
> with the current map.
> So, instead of just changing the SOAPActionInInterceptor, I am in favor of
> changing the implementation of the PROTOCOL_HEADERS map to support the
> case-insensitive lookup while preserving the original keys in the map.
> Another reason favoring this approach is that the current case-sensitive map
> can have a few other problems. For example, the map currently contains two
> Content-Type headers after it is created by AbstractHTTPDestination (over
> Jetty): one with "content-type" and the other with "Content-Type". And this
> is confusing and may lead to some conflicts. Another problem is the
> extraction problem for other headers when they are spelled in different mixed
> casing when they are passed.
> So, I think we should use a specific map class that matches the current
> interface but supports the case-insensitive lookup while preserving the
> original case sensitive keys. The attached ProtocolHeaders class satisfies
> this requirement. Its unit test class ProtocolHeadersTest is also attached.
> This class can be used in AbstractHTTPDestination to create the correct
> protocol headers map. I added a test case AbstractHTTPDestinationTest to
> check the extraction of the headers into the protocol headers map. The svn
> diff of 2.3.2 are attached.
> Please take a look at the files and let me know how you think.
> Thanks.
> Regards, aki
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
