cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CXF-3367) SOAPAction value not extracted in the inbound processing if the header name does not match exactly "SOAPAction"
Date Tue, 01 Mar 2011 15:49:36 GMT

     [ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Kulp resolved CXF-3367.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4


This should now be fixed.   I'd appreciate testing with the 2.3.4-SNAPSHOT after tomorrow's
builds (or from your own SVN checkout) just to make sure.   The merge from trunk -> 2.3.x
was bit complicated and I may have missed something.

> 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

        

Mime
View raw message