POSTs return 415 in prod but not dev

[idan]

Hello! Minimal example here:

• Repo: https://github.com/githubnext/azuresvelte
• Live: https://black-tree-066defe1e.5.azurestaticapps.net/

Reproduction steps:

• From /, click on either the "login" or "logout" buttons to trigger a form POST to /auth.
• In development, everything works
• When deployed to ASW, it throws a 415. The error page is sveltekit-generated, which means that ASW is working, but for some reason it's failing whatever check sveltekit before it throws a 415. I'll dig more into that.

I'm using Svelte 5.0.0-next.172, not sure if that's related — I'll try to make a svelte 4 example next and see if I get the same behavior.

[idan]

I tried the same project with the Azure SWA CLI locally, it works correctly there (but not in prod).

[idan]

OK, after further playing, it looks like any form submitted with no body is broken only on Azure.

https://black-tree-066defe1e.5.azurestaticapps.net/ -> see the difference between clicking on login (works) and logout (415).

the difference is a hidden field on the form:

<form method="POST" action="/auth?/login">
	<input type="hidden" name="foo" value="bar" />
	<button>Login</button>
</form>

<form method="POST" action="/auth?/logout">
	<button>Logout</button>
</form>

✅ Both actions work in local dev (npm run dev)
✅ Both actions work with the SWA CLI (npm run build && swa start)
🚫 Only the first one works when deployed

[geoffrich]

Thanks for the detailed investigation and repro! I did some digging and here's what I found:

When calling a form action, SvelteKit validates that your request has the correct content-type.

Normally when submitting a form, it has the "content-type" header set to "application/x-www-form-urlencoded". This is also present in the request passed to SvelteKit and everything works.

However, when you submit a form with no data, the Azure Function is stripping the "content-type" header, even though the raw POST request from the browser has it. This triggers the content-type check when SvelteKit handles the request.

You can see what is present on the request passed to the Azure function by logging out context.req.headers on the platform object.

This doesn't happen in dev because that's just running SvelteKit (no Azure), and the SWA CLI must not be replicating this behavior.

This seems like a bug for Azure Functions to fix (though idk if it would be prioritized). In the meantime, the adapter could add the content-type header back based on a heuristic, e.g. if POST and no body, then set a content-type header.

[idan]

Yup, got it!

I've also been bitten by #171 and Azure silently dropping cookies.

Do you want me to author a short "Gotchas" section for the readme about this stuff? I'd hate for anyone else to retread my steps and scratch their heads.

[geoffrich]

Yes, that would be appreciated!

I'm hoping to get a fix into the adapter for this content-type issue, but might as well add it to the Gotchas section in case that takes longer than expected.

I'm not sure the cookie issue can be worked around on the adapter end, so that would be good to document.

[geoffrich]

I opened Azure/static-web-apps#1512 to track the issue on the SWA side. It seems to be specific to Azure functions used with SWA - a standalone Azure function did not reproduce the issue.

In the meantime, v0.20.1 of this adapter should have a workaround for the issue.