Invalid boundary for multipart/form-data

[Dronakurl]

I am trying to include a multipart/form-data request and I always end up with the above error.

These are the relevant parts of the config:

chains:
  auth_token:
    source: !request
      recipe: login
    selector: $.token
  image:
    source: !file
      path: Pictures/xx_1.jpg
      post_person: !request
        name: Upload Person
        method: POST
        url: "{{server}}/api/people"
        headers:
          Accept: application/json
          Content-Type: "multipart/form-data"
        authentication: !bearer "{{chains.auth_token}}"
        body: !form_multipart
          name: John
          picture_path: "{{chains.image}};type:image/jpeg"

The corresponding curl command works fine:

curl -X POST "http://localhost:5150/api/people" -v \
  -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJwaWQiOiJmODVjZGM0MC1kOGQ2LTRmMWQtOWY0My05NDE4Y2IyZmI5ZGYiLCJleHAiOjE3NTM3OTUzMDl9.nO2l6BRL9whHf-suyOKUDDOiMkEvomzaTyBUGWERVDDVSvO9FO1eGOrJvip7sY-S9R4nEzMz-unccwYf_dqYaQ" \
  -F "name=John" \
  -F "picture=@Pictures/xx_1.jpg;type=image/jpeg"

It would be great if someone could have a look for some obvious errors. I could generate a more complete example.
The backend is an axum webserver with no special settings considering boundaries.

[Dronakurl]

I fixed it: I just head to remove the "Content-Type":

      post_person: !request
        name: Upload Person
        method: POST
        url: "{{server}}/api/people"
        headers:
          Accept: application/json
        authentication: !bearer "{{chains.auth_token}}"
        body: !form_multipart
          name: John
          picture: "{{chains.image}};type:image/jpeg"

[LucasPickering]

Glad you figured this out, I actually didn't catch that while reading. This did make me notice a shortcoming here though, which is that you can't customize the MIME part of the Content-Type header for a multipart request. I doubt it's useful very often, but curl does support that. In this case, it means your original request would've worked because the boundary wouldn't have been dropped from the Content-Type. I opened an issue with reqwest (the HTTP library that Slumber uses) to support this: seanmonstar/reqwest#2774