0

I have a Javascript front end and a Java back end. For the front end HTML and Javascript I used a solution that someone else already provided here on Stack overflow.

HTML (provided):

<input type="file" name="file" onchange=angular.element(this).scope().uploadedFiles(this.files)"/>

JAVASCRIPT/Controller:

$scope.uploadFiles = function(files) {
    var fd = new FormData();
    //Take the first selected file
    fd.append("file", files[0]);
    var uploadUrl = GlobalService.resourceUrl('/equipment/imageupload');

    $http.post(uploadUrl, fd, {
        withCredentials: true,
        headers: {'Content-Type': 'application/json' },
        transformRequest: angular.identity
    });
};

Backend method reached via REST (Java code)

@POST
@Path("/imageupload")
@Consumes(MediaType.APPLICATION_JSON)
public void uploadImage(InputStream uploadedStream)
{
   try
{
   File f = new File("C:\\Users\\myself\\myImage.jpg);
   OutputStream os = new FileInputStream(f);
   byte[] buf = new byte[1024];
   int len;
   while ((len = uploadedStream.read(buf)) > 0)
   {
      os.write(buf,0,len);
   }
   uploadedStream.close();
   os.close();
}
catch (Exception e)
{
   System.out.println("ERROR Uploading Image File);
}
System.out.println("Read input stream complete.");
}

When I select a file the post occurs and my Java backend code is reached correctly. The following is printed to the console:

-------WebKitFormBoundaryRANDOCHARACTERS
Content-Disposition: form-data; name = "file"; filename="mySourceImage.jpg"
Content-Type: image/jpeg

A LONG GROUP OF CHARACTERS THAT MUST BE THE IMAGE CONTENT

The uploaded file is larger than the source file. Uploaded server file = 53020 bytes in length, source client file = 52799 bytes in length. Does anybody have any idea what is causing this problem?

EDIT: Somebody asked for a printout of the two files, and what I'll do is post some of the results of the windows command fc /b. Problem is I do not have Internet access on the same machine as I develop on, and there is no network path between them. fc /b ORIGINALFILE UPLOADEDFILE This is the result for a PNG file I uploaded, which has the same type of problem: (LEFT = client original PNG file, RIGHT = uploaded PNG file)

00000000 89 2D
00000001 50 2D
00000002 4E 2D
00000003 47 2D
00000004 0D 2D 
00000005 0A 2D
00000006 1A 57
00000007 0A 65
00000008 00 62
00000009 00 4B

Starting here you get the ?PNG that the client PNG file started with: (ONLY SERVER FILE BYTE COLUMN SHOWN HERE:)

00000086 89
00000087 50
00000088 4E
00000089 47
0000008A 0D
0000008B 0A
0000008C 1A
0000008D 0A
0000008E 00
0000008F 00

I hope that is somewhat illuminating. In the case of the png file, the Server file is 180 bytes longer than the client. Since there seems to be 134 characters of Junk at the front of the uploaded PNG file, it is not as simple as just truncating the first N bytes from the uploaded PNG file.

calvinnme
  • 17
  • 6
  • any way you can post the file content? – Ben Glasser May 02 '19 at 17:40
  • Would you like to see the results of fc /b that I did on the two files? The problem is I have internet access on one machine AND I do development on another machine. There is no internet connection between them, so I just can't bring the file over and attach. I'll print out some of the relevant parts of the binary compare if it will help clarify the situation. – calvinnme May 02 '19 at 17:45
  • just diff the files and see whats different – Ben Glasser May 02 '19 at 17:59
  • I don't have Unix so I can't do a diff, but everything is different. There is some extra data at the beginning of the uploaded file, but just chopping that off won't fix it. See my byte by byte pseudo diff files above. Thanks for looking at this. – calvinnme May 02 '19 at 18:12
  • 1
    why is the content type (both on the client and server) set to `application/json` instead of `multipart/form-data`? – tantalum May 02 '19 at 18:22
  • I tried multipart/form-data first, then switched to JSON. The results are the same. The byte by byte content of the uploaded file is the same, the size mismatch is the same. It makes no difference. – calvinnme May 02 '19 at 18:27
  • Try `Content-Type: application/octet-stream` for both client and server. Sometimes the client content-type handling is not same at server end so just try and look into more about content-type options. – Abhishek May 02 '19 at 18:41
  • Nope. application/octet-stream yields exactly the same result. This CAN'T be THAT difficult. I'm sure somebody must have uploaded image files in this way before. – calvinnme May 02 '19 at 19:14
  • When posting data using the [FormData API](https://developer.mozilla.org/en-US/docs/Web/API/FormData), it is important to set the content type to `undefined`. – georgeawg May 02 '19 at 22:20
  • I'll give that a try tomorrow, although I think I did try that in the beginning and the REST ContainerRequestFilter, ContainerResponseFilter didn't accept it. May I ask why this is so important since it seems from what I am seeing on my console that the back end recognizes the incoming data as JPEG? Thanks for your time. – calvinnme May 02 '19 at 22:37
  • Someone marked my question as a duplicate, and I don't think that is true because the other question involves PHP. I must use REST and Java for what I am doing. – calvinnme May 02 '19 at 22:43

0 Answers0