Based on Keith's feedback:

1) Consider passing stream as message content instead of reading into byte array. The upside is that this is one less copy of the request content in memory. The (potential) downside is that if any processing of the message happens after the connection is closed, the request stream state could be corrupted.

2) HTTP 200 check in OutboundHandler might be too narrow. Consider the following possibilities:

a) The HTTP endpoint replies with 204. There's no content in the body, but there can still be header content that's significant to the consumer.

b) The HTTP endpoint replies with 404. Should this be returned as a fault? Even if it's not, should the headers and content be returned on the OUT message?

c) The HTTP endpoints replies with 500. This definitely should be an error/fault. If the HttpClient code throws an exception when this occurs, then we might be covered (although headers still aren't copied IIRC). If not, then we need to handle it explicitly.

Of course, the above are just specific examples. We probably want a general strategy of just mapping the reply headers and content to the SY exchange regardless of HTTP code. The HTTP code should definitely make it into the context properties and we should also interpret that value when considering if the reply is an error/fault or not.

3) Capture and represent RequestInfo details similar to this:
https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html-single/ESB_Programmers_Guide/index.html#id18436650