Describe the bug

Since 0.29.0 (#1005), every multipart/form-data request body is sent with a fixed boundary:

headers["Content-Type"] = "multipart/form-data; boundary=+++"

httpx reads the boundary back from that header when it encodes files=, so the header and the body agree. But a boundary must not occur in the content it delimits (RFC 2046 §5.1.1), and a fixed three-character one can. An uploaded file that contains the bytes \r\n--+++ is split at that point: the server receives a truncated file, and the rest of it as a malformed extra part.

This used to work for endpoints with a single multipart/form-data body. Up to 0.28.x their _get_kwargs set no Content-Type, and httpx generated a random boundary for each request. #1005 fixed the endpoints with several body types, which sent no boundary at all (#947). As a side effect, the single-body endpoints changed from a random boundary to the fixed one.

OpenAPI Spec File

openapi: 3.0.3
info: {title: Boundary repro, version: "1.0"}
paths:
  /upload:
    post:
      operationId: upload
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                file: {type: string, format: binary}
      responses:
        "200": {description: OK}

Generated with openapi-python-client generate --path openapi.yaml --meta none --output-path client, then:

import email.parser, email.policy, io
import httpx
from client import Client
from client.api.default import upload
from client.models.upload_body import UploadBody
from client.types import File

content = b"first line\r\n--+++\r\nstill the same file\r\n"
sent = []
transport = httpx.MockTransport(lambda r: (r.read(), sent.append(r), httpx.Response(200))[2])
client = Client(base_url="http://test", httpx_args={"transport": transport})
upload.sync_detailed(client=client, body=UploadBody(file=File(payload=io.BytesIO(content), file_name="a.txt")))

request = sent[-1]
message = email.parser.BytesParser(policy=email.policy.HTTP).parsebytes(
    b"Content-Type: " + request.headers["content-type"].encode() + b"\r\n\r\n" + request.content
)
parts = list(message.iter_parts())
print(len(parts), parts[0].get_payload(decode=True))
# 2 b'first line'

The file arrives as b'first line', and the rest of it becomes a second part. A server sees the same: Rack 3.2.6, which Rails uses, parses this request into file = "first line" plus a stray parameter named text/plain.

Desktop (please complete the following information):

• OS: Linux (Ubuntu)
• Python Version: 3.12.13
• openapi-python-client version: 0.29.1 (httpx 0.28.1)

Additional context

Two ways to keep #1005's fix without the fixed boundary:

1. A random boundary for each request, in the template. For example, boundary = secrets.token_hex(16) in _get_kwargs, used in the header. httpx would then encode the body with it, as it does with +++ today. httpx's own default is 16 random bytes in hex.
2. No Content-Type for an endpoint whose only body is multipart/form-data, as before 0.29.0, so that httpx sets the header with its own random boundary. Only the endpoints with several body types would need the explicit header from (1).

In practice a collision needs those exact seven bytes in the uploaded content, so it is rare with binary files. But it silently truncates the file, and it reaches the server as a successful upload.