anchor.diff:  
   When streaming to the HTTP response (for example, `text/event-stream`,
   `application/stream+json`), it is important to send data periodically, in order to
  -reliably detect a disconnected client sooner rather than later. Such a send could be an
  +reliably detect a disconnected client sooner rather than later. Such a send could be a
   comment-only, empty SSE event or any other "no-op" data that would effectively serve as
   a heartbeat.
   
  
positive.code: `Decoder` and `HttpMessageReader` implementations that buffer some or all of the input
  stream can be configured with a limit on the maximum number of bytes to buffer in memory.
  In some cases buffering occurs because input is aggregated and represented as a single
  object, e.g. controller method with `@RequestBody byte[]`, `x-www-form-urlencoded` data,
  and so on. Buffering can also occurs with streaming, when splitting the input stream,
  e.g. delimited text, a stream of JSON objects, and so on. For those streaming cases, the
  limit applies to the number of bytes associted with one object in the stream.
  
  To configure buffer sizes, you can check if a given `Decoder` or `HttpMessageReader`
  exposes a `maxInMemorySize` property and if so the Javadoc will have details about default
  
negative.code: `MultipartHttpMessageReader` and `MultipartHttpMessageWriter` support decoding and
  encoding "multipart/form-data" content. In turn `MultipartHttpMessageReader` delegates to
  another `HttpMessageReader` for the actual parsing to a `Flux<Part>` and then simply
  collects the parts into a `MultiValueMap`. At present
  https://github.com/synchronoss/nio-multipart[Synchronoss NIO Multipart] is used for the
  actual parsing.
  
  