Add recommendation for original multipart filename

See gh-26299
This commit is contained in:
Rossen Stoyanchev
2021-01-12 17:28:44 +00:00
parent c3c36ab498
commit a7413ea76b
3 changed files with 8 additions and 4 deletions

View File

@@ -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>

View File

@@ -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()

View File

@@ -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]]