415 Through a Proxy? Match the Request Type to Its Actual Body

An API returns 415 through a proxy even though the request contains the right business fields. Check the representation sent on the wire before changing the exit. A JSON object, a URL-encoded form and a multipart body can carry similar values but require different serialization and metadata.

This guide proposes small tests on an owned or explicitly authorized endpoint. It does not report an executed compatibility result, and no proxy product can make an unsupported destination format valid merely by transporting it.

1. Record the endpoint contract

MDN describes 415 Unsupported Media Type as refusal of an unsupported request format. The issue can involve Content-Type, Content-Encoding or examination of the content itself. A status code alone does not tell you which field or component rejected the request.

Write down the exact URL, method, API version, accepted request media types, required parameters, request content coding and a minimal valid synthetic object. Use the destination's documentation and owner confirmation. A response hint such as Accept-Post can assist when present, but its absence is not permission to guess.

Keep three concepts separate: Content-Type describes this request body's representation; a request Content-Encoding declares an applied content coding; Accept expresses a preference for the response. Changing Accept does not serialize the request into a supported format.

2. Inspect the actual request boundary

1. Use a staging receiver without payment, email or customer-data side effects.
2. Record the effective target URL and method, then capture sanitized request metadata at the client and authorized receiver.
3. Check the body bytes or a safe synthetic-body sample, rather than only the in-memory object before serialization.
4. Compare declared media type, parameters and content coding with the receiver's parser selection.
5. Save a case ID, client version, body length and synthetic digest; redact credentials and personal information.

A default header installed by a shared client can survive after the calling code switches body formats. Inspect the final merged headers, including request interceptors and wrappers. If a redirect occurs, inspect the actual receiving hop rather than assuming it received the original method and body.

3. Build one valid control before negative cases

For a documented JSON endpoint, serialize the harmless fixture as JSON using the client's supported serializer and send the documented media type. Confirm the receiver parsed the expected fields and returned its declared successful outcome. A 2xx status with an ignored or empty object is not a passing control.

Next change only the declared media type on the same small body in staging. Record the expected rejection from the endpoint contract. Do not require every implementation to return 415 for every malformed input: invalid syntax or validation failures may use different documented responses.

Restore the valid control after the negative case. If it also fails, stop and check state, routing and configuration before attributing the change to media type.

4. Let browser FormData own its boundary

For an endpoint documented to accept multipart forms, create a small FormData fixture with the exact required field names. MDN advises letting the browser set Content-Type when sending FormData with Fetch or XMLHttpRequest so that its boundary matches the generated body.

Remove a conflicting global JSON header or manually written multipart header for this request. Do not copy a boundary from an old trace into a newly generated body. On a non-browser client, use its multipart builder and the header it supplies as one coordinated pair; verify that client's documentation.

Separate the top-level multipart media type from a file part's own type and filename. Renaming an extension or changing a part label does not convert the file's bytes. Keep fixtures valid for the target's documented file policy.

5. Change content coding as a complete operation

If request compression is explicitly supported, test a separate valid encoded fixture with a matching coding declaration. Plain JSON mislabeled as compressed content is not that fixture. Likewise, removing a coding header while retaining compressed bytes leaves a mismatch.

Start with an uncompressed control only when the contract allows it. Change actual encoding and the declaration together, then check the decoded synthetic fields at the receiver. Keep body size, parser limits and expected validation outcomes recorded so a different rejection is not silently classified as a 415 failure.

6. Compare routes and choose the correction

Run independently reset control cases through an approved baseline and proxy path, holding client version, target, format and fixture constant. Compare receiver observations. In an HTTPS tunnel, do not assume the forwarding proxy can inspect the encrypted target body; identify any owned TLS termination and parsing layers before blaming a transport hop.

The 98IP dynamic residential IP page is relevant when choosing access for authorized regional API tests. Check the API configuration page for current connection and account options. Product access does not define the destination's accepted representations or prove compatibility with a particular serializer.

• Valid documented representation: receiver parses expected values.
• Same body with conflicting type: the declared rejection is observed.
• Browser FormData: generated boundary and body agree.
• File part: content, type and filename satisfy the file policy.
• Supported content coding: bytes and declaration agree after decoding.
• Restored control: correction works without changing unrelated route settings.

These cases are proposed and unexecuted. Correct the serializer and metadata together, then verify the result once with a fresh synthetic case. Do not rotate exits or repeatedly resend an unchanged unsupported format. If a write outcome is unknown, use the destination's receipt or readback rules before another submission.

FAQ and completion checklist

Can I fix 415 by changing only the header? Only if the existing bytes already match the documented representation. Otherwise the body must be generated correctly too.

Does the same object mean the same request? No. Different serializers can produce different representations from similar application values.

• Endpoint contract and a valid control are recorded.
• Actual body and final merged headers are inspected.
• FormData boundary ownership is preserved.
• Request coding and response preferences are distinguished.
• Receiver fields and final side effects are checked.
• Only authorized synthetic fixtures are retained, with bounded attempts and no untested compatibility promise.