You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Aki Yoshida (JIRA)" <ji...@apache.org> on 2011/02/25 22:09:21 UTC
[jira] Created: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
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
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
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CXF-3367) SOAPAction value not
extracted in the inbound processing if the header name does not match
exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002570#comment-13002570 ]
Aki Yoshida edited comment on CXF-3367 at 3/4/11 12:50 PM:
-----------------------------------------------------------
Hi Daniel,
I also tested the trunk 2.4.0-SNAPSHOT.
I'm attaching test_patches.tar.gz containing the test classes for 2.3.x and trunk
branches/2.3.x-fixes - AbstractHTTPDestinationTest.java
trunk - HeadersTest.java
regards, aki
was (Author: ay):
unit test classes for 2.3.x and trunk.in tar.gz
2.3.x - AbstractHTTPDestinationTest
trunk - HeadersTest
> 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, test_patches.tar.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
[jira] Resolved: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp reassigned CXF-3367:
--------------------------------
Assignee: Daniel Kulp
> 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.3.3
>
> 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
[jira] Updated: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aki Yoshida updated CXF-3367:
-----------------------------
Attachment: ProtocolHeaders.tar.gz
diff_rt.transports.txt.gz
diff_rt_transports.txt - svn diff of 2.3.2 rt/transports to add a new unit test
ProtocolHeaders.tar - ProtocolHeaders.java and ProtocolHeadersTest.java
> 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
>
> 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
[jira] Updated: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp updated CXF-3367:
-----------------------------
Fix Version/s: (was: 2.3.3)
2.3.4
> 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.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
[jira] Commented: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000676#comment-13000676 ]
Daniel Kulp commented on CXF-3367:
----------------------------------
I just made a commit to trunk that goes a slightly different route than this. I've pretty much gone through the entire code and made sure the PROTOCOL_HEADERS are always set to a TreeMap that is set for case insensitive compares. That should completely solve this.
That said, due to refactoring on trunk, it may take a little time to port it to the 2.3 branch. I'll do that tomorrow.
> 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.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
[jira] Updated: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aki Yoshida updated CXF-3367:
-----------------------------
Attachment: test_patches.tar.gz
unit test classes for 2.3.x and trunk.in tar.gz
2.3.x - AbstractHTTPDestinationTest
trunk - HeadersTest
> 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, test_patches.tar.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
[jira] Commented: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002830#comment-13002830 ]
Daniel Kulp commented on CXF-3367:
----------------------------------
Testcase patches applied to both branches. Thanks!
> 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, test_patches.tar.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
[jira] Commented: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999571#comment-12999571 ]
Aki Yoshida commented on CXF-3367:
----------------------------------
forgot to make a back reference to the mail thread
http://cxf.547215.n5.nabble.com/SOAP-header-wsdl2java-issue-td3399058.html
> 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: 2h
> Remaining Estimate: 2h
>
> 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
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (CXF-3367) SOAPAction value not extracted in the
inbound processing if the header name does not match exactly "SOAPAction"
Posted by "Aki Yoshida (JIRA)" <ji...@apache.org>.
[ 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