fix(functions): honor a caller's Content-Type override regardless of casing

[i-anubhav-anand]

🔍 Description

What changed?

FunctionsClient.invoke() decided whether to auto-set a Content-Type using a case-sensitive hasOwnProperty('Content-Type') check. HTTP header names are case-insensitive, so a caller-supplied lowercase content-type was not detected. This matches the header name case-insensitively before deciding to auto-set/serialize.

Why was this change needed?

With a lowercase content-type, the SDK fell into the auto-detect branch: it set its own Content-Type: application/json, JSON-stringified the body, then merged the caller's header on top — producing two conflicting Content-Type headers and ignoring the caller's intent. The docs state you can override by passing your own Content-Type header.

📸 Examples / Proof

Tests live in test/spec/params.spec.ts inside the existing body stringify with custom headers block (reusing its customFetch harness). On master the lowercase case fails:

- Expected:  ["application/vnd.api+json"]
+ Received:  ["application/json", "application/vnd.api+json"]

The lowercase test also asserts the request body is still '{"a":1}', locking in that the fix routes through the correct (JSON) serialization branch. The uppercase baseline is unchanged.

🔄 Breaking changes

• This PR contains no breaking changes

📋 Checklist

• I have read the Contributing Guidelines
• My PR title follows conventional commits: fix(functions): ...
• I have run pnpm nx format
• I have added tests
• Documentation (not needed)

📝 Additional notes

Rebased on master. Addressed review: moved the tests into params.spec.ts (removed the standalone file) and added the request-body assertion for the lowercase case.

[pkg-pr-new]

Open in StackBlitz

@supabase/auth-js

npm i https://pkg.pr.new/@supabase/auth-js@2455

@supabase/functions-js

npm i https://pkg.pr.new/@supabase/functions-js@2455

@supabase/postgrest-js

npm i https://pkg.pr.new/@supabase/postgrest-js@2455

@supabase/realtime-js

npm i https://pkg.pr.new/@supabase/realtime-js@2455

@supabase/storage-js

npm i https://pkg.pr.new/@supabase/storage-js@2455

@supabase/supabase-js

npm i https://pkg.pr.new/@supabase/supabase-js@2455

commit: 8e94d7a

[mandarini]

Hi @i-anubhav-anand, thank you so much for contributing to Supabase! 💚 This is a really nice catch, thanks for this PR!

I have just two small nitpicks, both optional and neither blocking:

1. The new test could live in the existing test/spec/params.spec.ts file, inside the body stringify with custom headers describe block. It already has the same custom fetch setup pattern, so adding your two cases there would keep all the Content-Type behavior in one place and avoid duplicating the client and capture harness. Totally your call.

2. The test asserts on the resulting Content-Type header, which is the important part. Would you be open to also asserting on the request body for the lowercase case? The fix changes which branch serializes the body, so a quick check that the body is still the expected JSON would lock in both halves of the behavior.

Neither of these changes what the PR does, and the fix itself looks good to me.

Thank you again for taking the time to track this down and write it up so clearly. It is contributions like yours that keep these libraries solid.

[mandarini]

Also, please @i-anubhav-anand rebase with master to fix CI!

[i-anubhav-anand]

Thanks @mandarini! 💚 Addressed both nitpicks:

1. Moved the two tests into test/spec/params.spec.ts inside the body stringify with custom headers block, reusing its existing customFetch harness (and removed the standalone file).
2. The lowercase test now also asserts the request body is '{"a":1}', locking in that the fix routes through the JSON serialization branch.

Also rebased on master to fix CI. Appreciate the kind words and the thorough review!