Allow custom headers for submit (and fetcher.submit)

[kentcdodds]

const data = useLoader()
const submit = useSubmit()

function makeSandwiches() {
  submit(sandwichForm, {
    method: 'post',
    headers: {'fly-force-instance-id': data.primaryFlyInstance},
  })
}

That's it. Just let me pass my own headers for stuff that wouldn't work without JavaScript anyway. My specific use case is to force a specific instance of my app to handle a request, but I'm sure there are other use cases too.

[jaruesink]

I guess the current way to do this would be to use hidden input values? (or query params on get requests)

[kentcdodds]

That won't work for me because these headers are used by Fly to determine which instance of my server to direct the request. If it's hit my application code it's already too late.

[tsvtt]

I wanted to submit a DELETE request with a custom header. It's unfortunate it isn't allowed.

[robertjpayne]

Just stumbled across this today, it makes implementing proper CSRF a pain. Even the OWASP cheatsheet says if possible use a header rather than a form field as it's more secure and only allowed for same-origin requests.

@kentcdodds did you find any work around on this or is it still off limits?

[kentcdodds]

I use remove-utils which uses a form field: https://github.com/sergiodxa/remix-utils#csrf

I don't know how a field is less secure than a header though 🤔 also, a header wouldn't progressively enhance so I wouldn't use it anyway.

[heivo]

When submitting large files with a multipart/form-data request it would make verifying the CSRF token much easier. Currently with unstable_parseMultipartFormData we cannot control the order in which the upload handler is invoked. So we might have to handle files before we can verify the CSRF token.

[kentcdodds]

It's all trade-offs. If you're happy with the lack of progressive enhancement then go for the header. Or maybe there's a way your backend could support both so it still progressively enhances as an optimization.

[hsdonkin]

Also ran into this, but in a bit of a weird use case. We have an action we're using internally, but also accessible to outside requests via API key. We can't add our auth headers, so we had to dump fetcher for fetch

[kentcdodds]

You can probably do this with clientLoader and clientAction :)

[sebastien-f]

Same need for me, to add a Bearer header.

[NareshBisht]

I also need this feature. Please Add it. Thank you

[Jazee6]

I also need this feature. :-)

[NareshBisht]

Devs please let us know if you plan to implement this feature. Thank you.

[s-abstract]

Would love to see this too, up

[kyrylo-soulandwolf]

+1

[iamsyh]

+1

[brophdawg11]

Closing in favor of the canonical custom-fetch proposal, being implemented in PR #15586.

The proposed HydratedRouter.unstable_fetch hook lets Framework Mode apps add custom headers to JavaScript-issued router data requests without monkey-patching window.fetch. For example, an implementation can return fetch(request, { headers }) with a Fly instance-selection header. Request URL/method, a named fetcher's context.fetcherKey, or an intent field inspected with request.clone().formData() can select the relevant submissions.

This is a global transport hook rather than a new headers option on submit/fetcher.submit; it does not carry arbitrary per-submission metadata. Browser-managed data prefetches bypass the hook, so disable data prefetching where custom headers are required. The implementation PR is still open; follow #15461/#15586 for progress.

Authored by an AI agent on behalf of @brophdawg11