INT-3934: HTTP Requests Without Content-Type

JIRA: https://jira.spring.io/browse/INT-3934

Coerce a missing Content-Type to `application/octet-stream`.

src/reference/asciidoc/http.adoc

@@ -55,6 +55,11 @@ The default converters encapsulate simple strategies, which for example will cre
 An additional flag (`mergeWithDefaultConverters`) can be set along with the list of custom `HttpMessageConverter` to add the default converters after the custom converters.
 By default this flag is set to false, meaning that the custom converters replace the default list.
 
+The message conversion process uses the (optional) `requestPayloadType` property and the incoming `Content-Type` header.
+Starting with _version 4.3_, if a request has no content type header, `application/octet-stream` is assumed, as
+recommended by `RFC 2616`.
+Previously, the body of such messages was ignored.
+
 Starting with _Spring Integration 2.0_, MultiPart File support is implemented.
 If the request has been wrapped as a _MultipartHttpServletRequest_, when using the default converters, that request will be converted to a Message payload that is a MultiValueMap containing values that may be byte arrays, Strings, or instances of Spring's `MultipartFile` depending on the content type of the individual parts.
 

src/reference/asciidoc/whats-new.adoc

@@ -85,3 +85,10 @@ pushing to the left end and reading from the right end.
 It is now possible to configure the reading and writing direction using `rightPop` and `leftPush` options for the
 `RedisQueueMessageDrivenEndpoint` and `RedisQueueOutboundChannelAdapter` respectively.
 See <<redis-queue-inbound-channel-adapter>> and <<redis-queue-outbound-channel-adapter>> for more information.
+
+==== HTTP Changes
+
+Previously, with requests that had a body (such as `POST`) that had no `content-type` header, the body was ignored.
+With this release, the content type of such requests is considered to be `application/octet-stream` as recommended
+by RFC 2616.
+See <<http-inbound>> for more information.