Multipart name and filename come through inverted in Part

[alexvigdor]

• Framework version: 1.3.1
• Implementations: Core

Scenario

Multipart file uploads come through with the field name and filename inverted when retrieved from a Part obtained from the servlet request, compared to POSTing directly to an application running locally and not in lambda under aws-serverless-java-container, i.e. the behavior is inconsistent with tomcat and jetty.

This even stands out when you look at the two lines of code - the way the variables are names makes it clear their assignment has been swapped.

https://github.com/awslabs/aws-serverless-java-container/blob/e4f4d4de6016a60d3fe728181d24aa4d91e645ec/aws-serverless-java-container-core/src/main/java/com/amazonaws/serverless/proxy/internal/servlet/AwsProxyHttpServletRequest.java#L712

Expected behavior

Part should be received with name set to the form field name and submittedFileName containing the name of the file attachment.

Actual behavior

Part is received with name set to the file attachment name and submittedFileName set to the form field name, the inverse of what is expected.

Steps to reproduce

Using a rest client like POSTMAN, attempt to upload a file input into a POST API; for example submit a file named "sample-image.jpg" into a form field named "image". The results will come through inverted. Here is sample debug logging code for the handler:

Collection<Part> parts = httpServletRequest.getParts();
List<Map> partDesc=null;
if(parts!=null) {
	partDesc = new ArrayList<>();
	for(Part part: parts) {
		Map pd = new HashMap<>();
		pd.put("name", part.getName());
		pd.put("size", part.getSize());
		pd.put("type", part.getContentType());
		pd.put("filename", part.getSubmittedFileName());
		partDesc.add(pd);
	}
}
Map details = new HashMap();
details.put("method", httpServletRequest.getMethod());
details.put("contentType", httpServletRequest.getContentType());
details.put("servletPath", httpServletRequest.getServletPath());
details.put("contextPath", httpServletRequest.getContextPath());
details.put("pathInfo", httpServletRequest.getPathInfo());
details.put("parts", partDesc);
log.info("Handling request for "+details);

Full log output

INFO: Handling request for {method=POST, servletPath=, contextPath=, parts=[{filename=image, size=257753, name=sample-image.jpg, type=image/jpeg}], contentType=multipart/form-data; boundary=--------------------------788920253325468350269863; charset=ISO-8859-1, pathInfo=/data/image}

[sapessi]

Thanks for catching this @alexvigdor! We'll address it with the next release

[allinwonder]

@sapessi apart from this field inverted issue, there is another strange issue I am facing during image upload. The binary data has been encoded and led to corruptted image file after the upload.

the following is the original image content

the following is the Lambda saved image content

Due to time constraint, I have to use a workaround to base64 encode images before upload, in this way I can bypass this issue. By it led to 10 to 20% increase in the request payload, and slows down the request and user experience.

[sapessi]

Thanks for the feedback @allinwonder. Any chance you have some code I can use to replicate the issue. At the moment I have a unit test in the project to check the original file size and the test passes: Jersey resource and unit test.

The one thing that's worth pointing out here is that we configure the LambdaContainerHandler object to treat that content type as binary.

[sapessi]

Hey @allinwonder, I'm planning to push 1.3.2 out as soon as possible and I'd like to include a fix for this. Let me know if you had time to test with the binary content type config or you have some code I can use to replicate.

[sapessi]

Release 1.3.2 - which includes this fix - is on its way to maven central! Resolving this issue.