Add recommendation for original multipart filename

See gh-26299

Author: rstoyanchev

spring-web/src/main/java/org/springframework/http/codec/multipart/FilePart.java

@@ -36,7 +36,9 @@ public interface FilePart extends Part {
 	 * <p><strong>Note:</strong> Please keep in mind this filename is supplied
 	 * by the client and should not be used blindly. In addition to not using
 	 * the directory portion, the file name could also contain characters such
-	 * as ".." and others that can be used maliciously.
+	 * as ".." and others that can be used maliciously. It is recommended to not
+	 * use this filename directly. Preferably generate a unique one and save
+	 * this one one somewhere for reference, if necessary.
 	 * @return the original filename, or the empty String if no file has been chosen
 	 * in the multipart form, or {@code null} if not defined or not available
 	 * @see <a href="https://tools.ietf.org/html/rfc7578#section-4.2">RFC 7578, Section 4.2</a>

spring-web/src/main/java/org/springframework/web/multipart/MultipartFile.java

@@ -56,7 +56,9 @@ public interface MultipartFile extends InputStreamSource {
 	 * <p><strong>Note:</strong> Please keep in mind this filename is supplied
 	 * by the client and should not be used blindly. In addition to not using
 	 * the directory portion, the file name could also contain characters such
-	 * as ".." and others that can be used maliciously.
+	 * as ".." and others that can be used maliciously. It is recommended to not
+	 * use this filename directly. Preferably generate a unique one and save
+	 * this one one somewhere for reference, if necessary.
 	 * @return the original filename, or the empty String if no file has been chosen
 	 * in the multipart form, or {@code null} if not defined or not available
 	 * @see org.apache.commons.fileupload.FileItem#getName()

src/docs/asciidoc/web/webflux.adoc

@@ -3002,8 +3002,8 @@ for the body. This allows a variety of async responses with `ResponseEntity` as
   asynchronously at a later point. This allows the response status and headers to vary
   depending on the outcome of asynchronous request handling.
 * `Mono<ResponseEntity<Mono<T>>>` or `Mono<ResponseEntity<Flux<T>>>` are yet another
-  possible, albeit less common alternative. They provides the response status and headers
-  asynchronously first and then the response body, also asynchronously at a second point later.
+  possible, albeit less common alternative. They provide the response status and headers
+  asynchronously first and then the response body, also asynchronously, second.
 
 
 [[webflux-ann-jackson]]