I have a SY 1.1.0 application with HTTP bindings and a simple requirement:
- read a number of well-known HTTP headers on request, and
- set other well-known HTTP headers on reply.
Implementing this, however, I have come to question how HTTP headers are handled by default in HTTPContextMapper and RESTEasyCoontextMapper.
Implementing requirement #2 is easy. Just add a context property and add a HTTP endpoint label to it. This works well enough because the context mapper logic is "matches(name) || property.hasLabel(...)".
Implementing requirement #1 is trickier, as the context mapper logic in this case is only "matches(name)". Okay, so I need to configure the context mapper includes. To make it easy for myself, I'll just collect all HTTP headers:
Now I have the HTTP headers collected for requirement 1, but now the context mapper will also leak all context properties as HTTP headers on the reply:
host: 127.0.0.1:8080 accept: */* org.switchyard.exchangeInitiatedNS: 607083392765785 user-agent: curl/7.27.0 org.switchyard.operationName: operation x-request-id: 0cc97eb4-fa14-487a-9589-06f3b8342f4b breadcrumbid: ID-noir-48260-1399200763256-9-6 org.switchyard.exchangeGatewayName: route-http-binding org.switchyard.relatesTo: ID-noir-48260-1399200763256-9-6 Content-Type: application/json Content-Length: 44 Date: Tue, 06 May 2014 23:50:55 GMT
So, the actual behavior I'm looking for is
- Collect all HTTP headers on the request, mark them with the HTTP label
- Collect all properties with HTTP label and set them as headers on the reply
In fact, before I dug into the implementation, I expected this sort of behavior by default. Is there any rationale for not doing point 1 above by default?
And, while on the subject, reading https://docs.jboss.org/author/display/SWITCHYARD/Message+Composition suggests Scope.IN and Scope.OUT property scoping (for properties, that came from the request and properties that will go to the reply), which I just cannot see in code. Is this documentation for Switchyard trunk, not the official release?