Support mixed multipart/form‑data text fields and file parts in one interaction

[jakubpawlik-identt]

Hi! I’m trying to write a Pact test in pact-python v3 where my consumer sends a single multipart/form-data request containing:

• JSON field (text)
• binary file (video.mp4)

However, the Pact on the provider side never sees the JSON field, it only sees the file part. As @YOU54F suggested that the core Pact Reference implementation may not currently support mixing JSON (or other form fields) with file parts in one multipart/form-data message.

Expected Behavior
The Pact should generate a multipart/form-data request that includes both:

• A file part named file containing the contents of video.mp4.
• A form field named text with the JSON/string value text_value.

Actual Behavior
Only the file part is received by the mock server.

Questions

1. Does the Pact Reference core support multipart requests with mixed JSON (or form) fields and file parts?
2. If not, is there a recommended workaround or timeline for adding this feature?
3. Would a new RFC be required to track and implement this functionality?

Thanks in advance, Jakub

---

I started here: pact-foundation/pact-python#1069

Hello guys!
Maybe an observation from my side: it is not clear for my side if multipart/form-data is supported in v3--> can we prepare an interaction using with_multipart_file and something else ?
I don't know how to attach a body as part in my multipart.
See this test for instance using only with_multipart_file
Any clue ?
Thanks!!
Olivier

Originally posted by @opicaud in #307

Hi! I encountered the same issue that Olivier mentioned. It's unclear to me how to use with_multipart_file while also including additional fields in the body. I have a case where my endpoint expects both a file and a text field in the request body, for example:

{
   "text": "text_value",
   "file": "video.mp4"
}

I tried doing it like this:

        .with_request(method="POST", path="/api/v1/check/")
        .with_body(
            body={
                "text": "text_value",
            },
            content_type="multipart/form-data",
            part="Request"
        )
        .with_multipart_file(
            part_name="file",
            path="fixtures/video.mp4",
            content_type="video/mp4",
            part="Request"
        )
        .will_respond_with(status=200)

I can't find an example of using it this way. Is it even possible to do that? In the example given above, when the test is triggered on the provider side, my service responds that the "text": "text_value" field is missing in the request.

Thanks in advance, Jakub

[rholshausen]

There are a couple of levels to this.

The Pact core library can match different parts of a multipart body, but it assumes the field parts are form fields and compares them with either a matching rule or as plain text. It won't know to handle JSON values there (they would need a content-type header added to the part and an update to the core to support that).

See this test as an example of matching rules being applied to different parts:

pact-reference/rust/pact_matching/src/binary_utils.rs

Line 993 in d9b2d33

fn match_mime_multipart_with_matching_rule() {

It can match JSON as a file part as it would with a normal JSON body (assuming the content type is set correctly.)

The next level up is that you are using Pact-Python, which uses the Pact FFI to call into the Pact core. That means this functionality needs to be supported both in Pact-Python as well as the FFI. At the moment there are functions in the FFI to setup a multipart body, but they require files as input.

[jakubpawlik-identt]

Thanks for the clarity, @rholshausen! I think I’ve got it now. Could you please confirm the next step? Should I open a feature request via the RFC process (https://github.com/pact-foundation/roadmap/blob/master/rfc/0000-rfc-process.md)?

Thanks again!
Jakub

[rholshausen]

No, I don't think that will help. Maybe reach out to the Pact Python maintainer (@JP-Ellis ), as there will need to be changes done there regardless of the solution.