Polishing

src/docs/asciidoc/web/webflux.adoc

@@ -586,7 +586,6 @@ Spring ApplicationContext, or that can be registered directly with it:
 	suspend fun getFormData(): MultiValueMap<String, String>
 ----
 
-
 The `DefaultServerWebExchange` uses the configured `HttpMessageReader` to parse form data
 (`application/x-www-form-urlencoded`) into a `MultiValueMap`. By default,
 `FormHttpMessageReader` is configured for use by the `ServerCodecConfigurer` bean
@@ -803,7 +802,7 @@ consistently for access to the cached form data versus reading from the raw requ
 `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 the
+collects the parts into a `MultiValueMap`. At present
 https://github.com/synchronoss/nio-multipart[Synchronoss NIO Multipart] is used for the
 actual parsing.
 
@@ -824,10 +823,11 @@ for repeated, map-like access to parts, or otherwise rely on the
 `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.
+object — for example, a controller method with `@RequestBody byte[]`,
+`x-www-form-urlencoded` data, and so on. Buffering can also occur with streaming, when
+splitting the input stream — for example, delimited text, a stream of JSON objects, and
+so on. For those streaming cases, the limit applies to the number of bytes associated
+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
@@ -851,7 +851,7 @@ To configure all 3 in WebFlux, you'll need to supply a pre-configured instance o
 
 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.
 
@@ -867,14 +867,12 @@ when consumed to avoid memory leaks.
 
 WebFlux applications generally do not need to be concerned with such issues, unless they
 consume or produce data buffers directly, as opposed to relying on codecs to convert to
-and from higher level objects. Or unless they choose to create custom codecs. For such
+and from higher level objects, or unless they choose to create custom codecs. For such
 cases please review the the information in <<core#databuffers, Data Buffers and Codecs>>,
 especially the section on <<core#databuffers-using, Using DataBuffer>>.
 
 
 
-
-
 [[webflux-logging]]
 === Logging
 [.small]#<<web.adoc#mvc-logging, Same as in Spring MVC>>#
@@ -1717,6 +1715,7 @@ under different URLs. The following example shows how to do so:
 <4> Add the registration.
 
 
+
 [[webflux-ann-methods]]
 === Handler Methods
 [.small]#<<web.adoc#mvc-ann-methods, Same as in Spring MVC>>#
@@ -3477,6 +3476,7 @@ use case-oriented approach that focuses on the common scenarios, as the followin
 ----
 
 
+
 [[webflux-caching-etag-lastmodified]]
 === Controllers
 [.small]#<<web.adoc#mvc-caching-etag-lastmodified, Same as in Spring MVC>>#