Your go-to microservice framework for any situation, from the creator of Netty et al. You can build any type of microservice leveraging your favorite technologies, including gRPC, Thrift, Kotlin, Retrofit, Reactive Streams, Spring Boot and Dropwizard.
@Consumes("multipart/form-data")
public class FileUploadService {
@Post("/upload")
public HttpResponse upload(@Param String text, @Param File file) throws IOException {
...
}
}
A client can send a multipart request that contains more than one file, even if /upload expects the request to contains one single file in the file field. Regardless of whether the received multipart request contains the file field or not, FileAggregatedMultipart.aggregateMultipart() will decode and store all file fields into the upload location (filesystem). It means, a client can incur unnecessary disk writes by sending the multipart requests like the following:
Two file uploads in the field file and file2. (not an error but unnecessary disk write for file2)
One file upload in the field foo. (an error with completely unnecessary disk write)
We could:
collect the list of required parameters during annotation scanning,
pass the list of required parameters to the resolvers,
so that the resolvers reject the requests with missing or unnecessary fields.
We might reject the requests with unnecessary fields only for a certain type of requests such as multipart file uploads, though, because sending an unnecessary fields are often harmless.
Alternatively, we might want to silently discard the body part of unnecessary fields, given that we limit the total content length anyway.
Given the following service:
A client can send a multipart request that contains more than one file, even if
/upload
expects the request to contains one single file in thefile
field. Regardless of whether the received multipart request contains thefile
field or not, FileAggregatedMultipart.aggregateMultipart() will decode and store all file fields into the upload location (filesystem). It means, a client can incur unnecessary disk writes by sending the multipart requests like the following:file
andfile2
. (not an error but unnecessary disk write forfile2
)foo
. (an error with completely unnecessary disk write)We could:
We might reject the requests with unnecessary fields only for a certain type of requests such as multipart file uploads, though, because sending an unnecessary fields are often harmless.
Alternatively, we might want to silently discard the body part of unnecessary fields, given that we limit the total content length anyway.