Jersey Multipart Form Data File Upload functionality appears broken

[seshuad]

• Implementations: Jersey

Scenario: Using Jersey 2 to implement Fileupload, The ServletInput Stream size does not match the size of the uploaded file as a result the uploads are getting corrupted.

Expected behavior

ServletInputStream size should match the size of the file being uploaded us Mulitpart Form upload.

Actual behavior

The ServletInputStream size does not match the size of the file being Uploaded. AwsProxyRequest maps the request body to a String which might be the cause.

@JsonIgnoreProperties(ignoreUnknown = true)
public class AwsProxyRequest {

private String body;
private String resource;

Steps to reproduce

Implement a Jersey Lamda Function with @FormDataParam for e.g.

public Response uploadFile(
@FormDataParam("file") InputStream uploadedInputStream,
@FormDataParam("file") FormDataContentDisposition fileDetail)

Full log output

[sapessi]

Hey @seshuad, the input model maps to a stream because that is indeed how Lambda receives the data - Lambda only supports JSON events so API Gateway and ALB automatically base64 encode the body before sending it to Lambda. The framework decodes the data before sending it to your implementation.

In API Gateway, you need to explicitly enable binary support for the content types you want. I'll try to replicate this issue over the next couple of days.

[seshuad]

@sapessi Thanks for the quick response. Tried enabling binary support for Content-Type: multipart/form-data in API Gateway but wasn't sure if I did it right. Please do let me know if you are abe to repro.

[sapessi]

@seshuad can you tell me what sizes you see?

System.out.println("File info: " + fileDetail.getName() + " " + fileDetail.getFileName() + " " + fileDetail.getSize());
System.out.println("Input size: " + uploadedInputStream.available());

[seshuad]

Here you go. this log is from trying to write to S3.

for a pdf file

com.amazonaws.SdkClientException: Data read has a different length than the expected: dataLength=243499; expectedLength=252786; includeSkipped=false; in.getClass()=class com.amazonaws.internal.ReleasableInputStream;

for a zip file

com.amazonaws.SdkClientException: Data read has a different length than the expected: dataLength=256116; expectedLength=270669; includeSkipped=false; in.getClass()=class com.amazonaws.internal.ReleasableInputStream;

[sapessi]

How does the SDK determine what the expected length was? Any chance you could paste the handler method implementation here?

If base64 decoding was the issue then I would expect the Jersey method to not even find the parameters, instead just receive a base64 blob it cannot make sense of.

[seshuad]

I sent the size from the client...

@post
@consumes({MediaType.MULTIPART_FORM_DATA, MediaType.APPLICATION_OCTET_STREAM})
public Response uploadFile(
@QueryParam("tenantId") String tenantId,
@QueryParam("poolId") String poolId,
@QueryParam("vmname") String vmname,
@QueryParam("logFileSize") long logFileSize,
@FormDataParam("file") InputStream uploadedInputStream,
@FormDataParam("file") FormDataContentDisposition fileDetail) {

    // check if all form parameters are provided

    if (tenantId == null || poolId == null || vmname == null || uploadedInputStream == null
            || fileDetail == null)
        return Response.status(400).entity("Invalid form data").build();


    Date currentDate = new Date(System.currentTimeMillis());
    SimpleDateFormat format1 = new SimpleDateFormat("yyyy-MM-dd");
    String dateString = format1.format(currentDate);

    SimpleDateFormat format2 = new SimpleDateFormat("HH:mm:ss.SSS");
    String timeString = format2.format(currentDate);


    String logFileName = S3Client.DCTLOGS_FOLDER + "/" + tenantId + "/" + poolId + "/" + vmname + "/"
            + dateString + "/" + timeString + "-" + fileDetail.getFileName();
    logger.log("Filename " + logFileName + " file size " + fileDetail.getSize());

    long fileSizeUploaded;

    try {
        fileSizeUploaded = s3Client.putObject(uploadedInputStream, logFileName, logFileSize);
    } catch (Exception se) {
        return Response.status(500).entity("Error uploading DCT Logs").build();
    }

    return Response.status(200).entity("Logs saved to " + logFileName + " size : " + fileSizeUploaded).build();
}

[seshuad]

With text files the stream appears to be the correct size

[sapessi]

Thanks for the additional info. The fact that it works fine with text file suggests that perhaps the request body is not base64 encoded. Quick test for this by injecting the ContainerRequest in your method.

public Response uploadFile(
        @QueryParam("tenantId") String tenantId,
        @QueryParam("poolId") String poolId,
        @QueryParam("vmname") String vmname,
        @QueryParam("logFileSize") long logFileSize,
        @FormDataParam("file") InputStream uploadedInputStream,
        @FormDataParam("file") FormDataContentDisposition fileDetail,
        @Context ContainerRequestContext req) {
    System.out.println("Is base64 encoded: " + ((AwsProxyHttpServletRequest)req.getProperty(JERSEY_SERVLET_REQUEST_PROPERTY)).getAwsProxyRequest().isBase64Encoded()
        );
...
}

[tedyu]

The output obtained from above statement is :

Is base64 encoded: false

[tedyu]

I modified getInputStream() method by calling body.getBytes() for multipart/form-data content type:

            log.info("body len: " + body.length());

            try {
                if (getContentType().startsWith("multipart/form-data")) {
                    bodyBytes = body.getBytes();
                } else {
                    if (encoding == null) {
                        log.info("Using ISO_8859 encoding");
                        encoding = StandardCharsets.ISO_8859_1.name();
                    }
                    bodyBytes = body.getBytes(encoding);
                }
            } catch (Exception e) {
                log.error("Could not read request with character encoding: " + SecurityUtils.crlf(encoding), e);
                bodyBytes = request.getBody().getBytes(StandardCharsets.ISO_8859_1.name());
            }

        log.info("Request size " + bodyBytes.length);
        ByteArrayInputStream requestBodyStream = new ByteArrayInputStream(bodyBytes);
        return new AwsServletInputStream(requestBodyStream, bodyBytes.length);

Here is the output:

[2018-12-28 07:43:35.525] 45ab77ea-0a74-11e9-9d0a-177d1431486c INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - body len: 88366 
[2018-12-28 07:43:35.588] 45ab77ea-0a74-11e9-9d0a-177d1431486c INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - Request size 159050 

[tedyu]

Here is AwsServletInputStream#read :

        @Override
        public int read()
                throws IOException {
            int readByte = bodyStream.read();
            bytesRead++;
            if (bodyStream.available() == 0) {
                log.info("has finally written " + bytesRead + " bytes with " + readByte);
                if (listener != null) {
                    listener.onAllDataRead();
                }
            }
            return readByte;
        }

Here is the output :

[2018-12-28 07:43:38.987] 45ab77ea-0a74-11e9-9d0a-177d1431486c INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 159050 bytes with 10 
[2018-12-28 07:43:38.988] 45ab77ea-0a74-11e9-9d0a-177d1431486c INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 159051 bytes with -1 
[2018-12-28 07:43:38.988] 45ab77ea-0a74-11e9-9d0a-177d1431486c INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 159052 bytes with -1 

I wonder why read() is called twice where return value is -1.
The outcome of the above change to getInputStream() method is that file uploaded to S3 is of size 0.

[tedyu]

Not sure it is related:
ReadListener is null for the AwsServletInputStream instance.

[tedyu]

Added the following two methods to AwsServletInputStream :

        @Override
        public void close() throws IOException {
            log.info("inside close");
            bodyStream.close();
        }

        @Override
        public int available() throws IOException {
            return length - bytesRead;
        }

However, there is no visible impact on the outcome of uploading the same pdf.
The log inside the close() method was not called.

[tedyu]

If I save the upload in a local file before calling putObject() to save on S3, the file size of the upload on S3 is no longer zero.
But the pdf file cannot be read since the length seen by AwsServletInputStream (from return value of getBytes) is much longer than the length of request body.

[tedyu]

I also tried StandardCharsets.UTF_16 and StandardCharsets.UTF_8 as parameter to getBytes().

StandardCharsets.UTF_16 resulted in 400 Bad Request - though the overridden close() was seen in CloudWatch log:

[2018-12-28 08:32:34.210] 1b4cbe59-0a7b-11e9-b672-d51a6567bc66 INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 176734 bytes with 10 
[2018-12-28 08:32:34.229] 1b4cbe59-0a7b-11e9-b672-d51a6567bc66 INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 176735 bytes with -1 
[2018-12-28 08:32:34.229] 1b4cbe59-0a7b-11e9-b672-d51a6567bc66 INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - has finally written 176736 bytes with -1 
[2018-12-28 08:32:34.286] 1b4cbe59-0a7b-11e9-b672-d51a6567bc66 INFO c.v.v.x.c.p.i.s.AwsProxyHttpServletRequest - inside close 

For UTF8, the behavior is the same as no-parameter getBytes().