[JBoss JIRA] Created: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
11:59 p.m.
HTTP request headers now nested inside RequestInfoMap property causes invisibility to
HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:01 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward reassigned JBESB-2814:
---------------------------------
Assignee: Tom Fennelly
Tom, I'm guessing you want this issue assigned to you since you have/are working on
the new http gateway. If you'd rather me fix this, let me know. I'm more than
happy to jump in and do it and/or test the webservice_proxy_security quickstart after the
fix.
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:03 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward commented on JBESB-2814:
-----------------------------------
Here's an example of an incoming ESB Message Properties:
{org.jboss.soa.esb.message.time.dob=Tue Sep 08 16:28:51 GMT-05:00 2009,
RequestInfoMap={protocol=HTTP/1.1, scheme=https, content-length=254, contentLength=254,
pathInfo=null, host=localhost:9443, serverName=localhost, user-agent=Jakarta
Commons-HttpClient/3.0.1, contextPath=/Proxy_Security/HelloWorldWS, remoteHost=127.0.0.1,
remoteUser=null, remoteAddr=127.0.0.1, content-type=text/xml;charset=UTF-8,
contentType=text/xml;charset=UTF-8, soapaction="", authType=null,
authorization=Basic YWRtaW46YWRtaW4=, queryString=null, characterEncoding=UTF-8,
localAddr=127.0.0.1, requestSessionId=null, requestPath=/,
requestURI=/Proxy_Security/HelloWorldWS/, pathInfoTokens=[Ljava.lang.String;@1ee3c8d,
localName=dwardlinux, method=POST}, org.jboss.soa.esb.message.time.dod=Tue Sep 08 16:28:51
GMT-05:00 2009}
You can see that "soapaction" is now nested inside "RequestInfoMap",
where it used to be a top-level ESB Message property itself.
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:05 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward commented on JBESB-2814:
-----------------------------------
One more thing: Shouldn't the JBossRemotingGatewayListener (when configured for http),
put the request headers in the same place as the http gateway, for consistency's
sake?
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:03 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
Tom Fennelly commented on JBESB-2814:
-------------------------------------
Something odd here Dave... you sure you're not using the old http-gateway? The new
one doesn't add headers under a "RequestInfoMap" property. The old one does
for sure.
What does you config look like? Should be using the new 1.2.0 namespace.
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:08 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward commented on JBESB-2814:
-----------------------------------
Okay, this could be an issue that is due to the webservice_proxy_security using the
jboss-esb-1.1.0.xsd configuration and the <http-provider><http-bus> and
<http-listener is-gateway="true" tags. When doing that, the
org.jboss.soa.esb.listeners.gateway.HttpMessageComposer is used. The other
webservice_proxy_* examples use thew new jboss-esb-1.2.0.xsd configuration and the
<http-gateway tag. When doing that, the
org.jboss.soa.esb.listeners.gateway.http.HttpMessageComposer is used (notice the
"http" sub-package difference).
So, I'm guessing I should upgrade the config to 1.2.0 and use the <http-gateway
tag. I'll have to figure out how to set the SSL configuration properly on the new
tag. What should we do about the old HttpMessageComposer usage? Something was changed
between the release of ESB 4.6 and the current trunk version... Unfortunately I'm
having a little trouble with svn history because things appear to have been moved around.
Also (and I haven't tried it yet), the new composer looks like it puts all the request
headers into a HttpRequest object, found in the ESB Message Properties under the name
"org.jboss.soa.esb.http.HttpRequest#request". I believe this would mean the
HttpRouter would still not be able to find the properties it's looking for...
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:10 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward commented on JBESB-2814:
-----------------------------------
Tom - Funny. I noticed that and was typing my last comment when you submitted yours; LOL.
What do you think of my latest comment?
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:12 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
Tom Fennelly commented on JBESB-2814:
-------------------------------------
Of course there's still the issue of mapping the headers.
The new gateway creates a HttpRequest object and sets it on the message. We could update
the HttpRouter to pick this up, or fall back to getting properties directly message
properties for backward compatibility.
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:14 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
Tom Fennelly commented on JBESB-2814:
-------------------------------------
Snap hehehe.... yep there's still an issue... easy to sort out though. Sorry I missed
it and thanks for catching it Dave :)
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: Tom Fennelly
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:36 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-2814) HTTP request headers now nested inside RequestInfoMap property causes invisibility to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward reassigned JBESB-2814:
---------------------------------
Assignee: David Ward (was: Tom Fennelly)
After chatting with Tom, I'm taking over this issue.
I'll change HttpRouter to first look for the request headers in their new location,
but fall back to direct properties if it's not there.
I'll also update the webservice_proxy_security quickstart to use the new configuration
as described here:
http://www.jboss.org/community/wiki/HTTPGateway#Security
HTTP request headers now nested inside RequestInfoMap property causes
invisibility to HttpRouter and dependents
---------------------------------------------------------------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: David Ward
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:48 p.m.
New subject: [JBoss JIRA] Updated: (JBESB-2814) HTTP request headers invisible to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward updated JBESB-2814:
------------------------------
Summary: HTTP request headers invisible to HttpRouter and dependents (was: HTTP
request headers now nested inside RequestInfoMap property causes invisibility to
HttpRouter and dependents)
HTTP request headers invisible to HttpRouter and dependents
-----------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: David Ward
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:50 p.m.
New subject: [JBoss JIRA] Closed: (JBESB-2814) HTTP request headers invisible to HttpRouter and dependents
[
https://jira.jboss.org/jira/browse/JBESB-2814?page=com.atlassian.jira.plu...
]
David Ward closed JBESB-2814.
-----------------------------
Resolution: Done
Fixed on trunk.
Committed revision 29277.
HTTP request headers invisible to HttpRouter and dependents
-----------------------------------------------------------
Key: JBESB-2814
URL: https://jira.jboss.org/jira/browse/JBESB-2814
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transports
Affects Versions: 4.7
Reporter: David Ward
Assignee: David Ward
Priority: Blocker
Fix For: 4.7
It appears the new http gateway on trunk is now nesting the incoming http request headers
into a ESB Message property of "RequestInfoMap". There is code assuming the
request headers would be top-level properties.
For example, HttpSOAPProxyTransport embeds usage of HttpRouter, setting it's default
configuration of "MappedHeaderList" to "Content-Type, Accept,
Authorization, SOAPAction". On lines 232-255 of HttpRouter (the setMappedHttpHeaders
and getHttpHeaders methods), the mapped headers are attempted to be pulled directly out of
the ESB Message Properties, *not* to first pull out the "RequestInfoMap" then
pull out the header properties from that map. This breaks the webservice_proxy_security
quickstart, but more importantly, it would break any code or configuration usage out there
where people are assuming the old location of the request headers.
I'm okay with the change to nest the request headers inside the RequestInfoMap
property, however 1) HttpRouter getHttpHeaders(Message,String):Object needs to be updated,
and 2) we need to make sure the release notes warns users of this change, just in case
there was custom code or configuration out there assuming the old property location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5398
days inactive
5399
days old
11 comments
2 participants
participants (2)
-
David Ward (JIRA) -
Tom Fennelly (JIRA)