[
https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002554#comment-13002554
]
Aki Yoshida commented on CXF-3367:
----------------------------------
Hi Daniel,
thanks for this change. I agree that the tree set is a better approach
as we don't have so many entries and the binary search is cheaper than
the cost of maintaining two hashmaps and running string conversions.
I tested 2.3.x-fixed (2.3.4-SNAPSHOT) today. I needed to change my
AbstractHTTPDestinationTest that I attached to the ticket.
That one was failing in 2.3.4-SNAPSHOT because the mocked
ServletRequest class was expecting a method call which was no longer
called in the 2.3.4 code. So I needed to adjust this mock class.
I haven't tried the trunk code. This test class for 2.3.x doesn't
match the signature of 2.4.0-SNAPSHOT and I can't directly use it to
test it. I can create a test case.
Should I attach them to this resolved ticket or send them to you by mail?
Thanks.
Regards, aki
> 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
> Assignee: Daniel Kulp
> Fix For: 2.4, 2.3.4
>
> Attachments: ProtocolHeaders.tar.gz, diff_rt.transports.txt.gz
>
> 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
