Method overrides

[Rich-Harris]

I could have sworn we'd already talked about this at some point, but I guess not.

Is your feature request related to a problem? Please describe.
Bewilderingly, the only valid <form> methods are GET and POST — in other words <form method="put"> is invalid, and will result in form.method === 'get'.

A popular workaround is to use a method override query string parameter, like so:

<form method="post" action="/todos/{id}?_method=put">
  <!-- form elements -->
</form>

(As evidence for the validity of this approach, there's an official Express middleware for it: https://www.npmjs.com/package/method-override).

It would be nice if such a thing existed in SvelteKit as well, since we want to encourage people to build apps that work with JavaScript disabled, and that's only really possible if you can use PUT and DELETE alongside GET and POST without having to resort to fetch.

Describe the solution you'd like
Since the ?_method=put cowpath already exists, I propose that we bake it into SvelteKit, while making it configurable:

// svelte.config.cjs
module.exports = {
  kit: {
    methodOverride: {
      key: '_method',
      allowed: ['post', 'put', 'delete']
    }
  }
};

Then, when any request that comes in where query.has(override), we change the request method before passing it to handle.

How important is this feature to you?
It would be possible to do in userland...

export function handle({ request, render }) {
  return render({
    ...request,
    method: request.query.get('_method') || request.method
  });
}

...but I think this is the sort of thing that belongs in the framework.

[Conduitry]

Looking at the readme of that middleware, are they actually blessing that particular query parameter name? The only thing I saw blessed was a particular HTTP header. Or are you saying this would be off by default and people would need to explicitly opt in and say what query parameter they want to use?

[Rich-Harris]

They're blessing it in the sense that it's in the README. I've seen it used in a couple of different places

I'm suggesting that _method would be the default, but you could change it to whatever:

// svelte.config.cjs
module.exports = {
  kit: {
    methodOverride: {
      key: 'httpverb',
      allowed: ['patch']
    }
  }
};

[Conduitry]

I think not having this be opt-in would just bother me, no matter what name we used or what level of blessed this was in that middleware. It could be that I just wasn't looking, but I've certainly not gotten the impression that this has been at all an established de facto standard.

[Rich-Harris]

I don't know if I'd go as far as saying it's a de facto standard, just that it's a cowpath. Can you articulate why it bothers you? The framework is already doing other frameworky things like generating 304s and parsing bodies and serving static assets, is this so different?

[Conduitry]

That a 304 means a redirect and that a given content-type means that this is form data or that this is JSON data are all established real standards. That ?_method=put means "pretend this is a PUT" is not a standard. It's ascribing some additional meaning to something that officially has no particular meaning.

If this is an appeal to "2.4 million downloads of this package per month can't be wrong" then I will remind you about other commonly done things that you have complained about vehemently in the past. And if you still think this is a good idea, I'm not going to keep arguing about it, because it doesn't seem that awful as a default.

[Rich-Harris]

The only reason I'm keen on it is that without method overrides there's basically no way to build a CRUD app that doesn't rely on JS, AFAICT, and if 'you can build robust apps that don't make anti-SPA-fanatics froth at the mouth' is one of the selling points of SvelteKit (which I think it is!) then maybe it warrants being part of the framework.

At the same time, I've rarely regretted listening to you in the past. I think we need some more opinions!

[GrygrFlzr]

For consideration - prior art using the _method hack:

• Twitter PowerTrack API
• Ruby on Rails
• Laravel
• Symfony
• CodeIgniter
• Java Spring
• Rust hyper
• Rust rocket
• Elixir Phoenix.HTML
• HTTP Method Override for Go
• WeatherSource API

[Rich-Harris]

Thanks, that's very useful context. I see a few of these:

<input type="hidden" name="_method" value="PUT">

Perhaps we should support both? In which case it probably would need to be in the framework, since that would be more finicky to do in userland

[benmccann]

I'm in favor of this proposal. It's something I don't want to have to think about implementing as a user and would be happy to have the framework handle. The only danger I see is if I had a form with an input named _method but that seems quite unlikely and the benefits far outweigh the risks in my opinion

[Conduitry]

I'm not at all against this being included in the framework; what I'm concerned about is this being non-standard behavior that is being sent to folks as a default.

[lukeed]

Gross 😅

Better to scaffold a server-side POST /items/:id/update endpoint imo. It can even be an alias to the same handler for PUT route.

Methods and status codes are fundamental building blocks. Paths can be reworked if need be. And there's a much deeper cow path for shuttling everything thru POSTs if needed.

[Rich-Harris]

Huh. I find it much grosser to update or delete a resource with a POST request. If HTTP methods mean anything at all, then POST /items/xyz/update means 'create a new resource of the type /items/xyz/update', which is incoherent.