Multipart/form-data first element empty when receiving file via Published REST-service

0
I am currently working on a connection between 2 of our apps in which I need to send FileDocuments as well as some metadata in the form of a NP-entity. I want to do this with a Form-data request because the data needs to be send in 1 request.One application does a POST-request to the Published REST-service of the other app and this is where the problem seems to be. The request seems to be fine but receiving/parsing the request seems to go wrong.Whenever I send a FileDocument above a certain size (somewhere between 175264 - 212832 bytes) the first 'Form'-parameter will be omitted/empty. As you can see from the images I've added a boolean 'TEST' which is completely empty (even the variable type is Empty) whenever I send a 218kB file and when I send a 175kB file it is received normally. The weird thing is that it is always the top parameter that is omitted/empty when the file is above a certain size even if it is the FileDocument itself.From what I've tested it seem that the rest of the request is parsed/handled correctly (that is all 'Form'-parameters except the top one) . I don't think, however, it is a viable solution to add a sort of dummy parameter which will be empty and then send the real data in the 2 other parameters?Has anyone experienced the same problem? What could be the problem and how can I solve this? Thanks in advance,Nick
asked
2 answers
0

If you are running on-premise, you can define this in your runtime YAML.


runtime:
  jettyOptions: |-
    {
      "max_form_content_size": 10485760
    }


Then redeploy the app so it takes effect.


If this resolves your issue, kindly mark it as accepted.


answered
0

Hi Nick van de Munt


Mendix's Published REST service parses multipart form-data parts sequentially in order. When a file part exceeds a certain size (~175KB), the internal read buffer fills up mid-stream, and Mendix's parser loses the boundary marker between parts. When it re-syncs, it skips the first parameter entirely because it already consumed part of it while scanning for the boundary.The threshold you're seeing (~175–212KB) is consistent with a default buffer size of 8192 bytes × 24 iterations or similar internal chunking behavior in the Mendix runtime's HTTP body parser. the best method is to ensure the FileDocument is always the last part in the multipart body, and all metadata parameters come before it. for example[ only If you're using a Java Action or HTTP Request activity, construct the multipart body explicitly:



java

MultipartEntityBuilder builder = MultipartEntityBuilder.create();
builder.setMode(HttpMultipartMode.BROWSER_COMPATIBLE);

// Always add metadata parts FIRST
builder.addTextBody("TEST", "true", ContentType.TEXT_PLAIN);
builder.addTextBody("Metadata", yourJsonString, ContentType.APPLICATION_JSON);

// File ALWAYS goes last
builder.addBinaryBody(
    "FileDocument",
    fileBytes,
    ContentType.DEFAULT_BINARY,
    fileName
);



multipart/form-data order:

1. TEST (boolean) ← metadata first

2. YourNPEntity (JSON) ← metadata second

3. FileDocument ← file ALWAYS last


If you manage the Mendix runtime deployment, you can try increasing the HTTP body buffer size in your m2ee.yaml or custom runtime settings:

yaml

custom:
  com.mendix.http.multipart.maxFileSize: 104857600   # 100MB
  com.mendix.http.multipart.fileSizeThreshold: 0     # always stream to disk
  com.mendix.http.multipart.maxRequestSize: 209715200 # 200MB total

These map to Apache Commons FileUpload settings which Mendix uses under the hood. Setting fileSizeThreshold to 0 forces all parts — including small ones — to be streamed to disk rather than buffered in memory, which eliminates the buffer boundary issue entirely.


I hope this is quit a lot of data but this can fix the issue

answered