Add functionality to override http methods (issue #1046) #2989

am283721 · 2021-12-06T02:30:05Z

In short: Given that the only valid <form> methods are GET and POST, functionality is provided to override this limitation and allow the use of other HTTP verbs. This is particularly helpful when ensuring your application works even when javascript fails or is disabled.

I could see this potentially needing to be an RFC due to either the impact of the change or the differences in opinion about how it should be implemented or what the default config values should be. Let me know if this is the case.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
This message body should clearly illustrate what problems it solves.
Ideally, include a test that fails without this PR but passes with it.

Tests

Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

See: sveltejs#1046

changeset-bot · 2021-12-06T02:30:07Z

🦋 Changeset detected

Latest commit: e3cdab5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@sveltejs/kit	Patch
create-svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

benmccann · 2021-12-13T04:20:16Z

pnpm-lock.yaml

@@ -30,7 +30,7 @@ importers:
      '@sveltejs/eslint-config': github.com/sveltejs/eslint-config/9a7d728e03ac433e5856a6e06775c17ee986d641_d9525e585486a10ae6317f3f61e9597f


you shouldn't need to modify the lockfile. there's a merge conflict since this file is being changed, so it'd be nice to drop it from the PR

Reverted to the previous lockfile. It appears the build is failing due to the new config options.

Unexpected option config.kit.methodOverride

I'm assuming Netlify is building the create-svelte apps using the version of sveltekit provided by npm, and not this version of the kit? How is this typically handled?

documentation/docs/01-routing.md

benmccann · 2021-12-13T04:27:49Z

documentation/docs/01-routing.md

+Given that the only valid `<form>` methods are GET and POST, functionality is provided to override this limitation and allow the use of other HTTP verbs. This is particularly helpful when ensuring your application works even when javascript fails or is disabled.
+
+- Disabled by default to prevent unintended behavior for those who don't need it
+- For security purposes, the original method on the form must be `POST` and cannot be overridden with `GET`


this is a bit vague. it'd be better if we can say something more specific

Suggested change

- For security purposes, the original method on the form must be `POST` and cannot be overridden with `GET`

- To protect against CSRF attacks, the original method on the form must be `POST` and cannot be overridden with `GET`

Agreed. Although I'm not sure if this is for CSRF protection or for protection against other attack vectors (cache poisoning was the example given: #1046 (comment)).

Unfortunately I lack expertise in this field. Maybe @Prinzhorn could approve your suggestion or provide a more detailed/accurate statement?

I don't think we need to be that specific and it's also not just a security thing. GET has vastly different semantics from POST, PUT etc. We should focus on why the feature exist, what problem it solves. I don't see any problem being solved by changing the method from/to GET.

I'd shorten the paragraph and the two bullet points to something like:

In contrast to fetch the only valid methods for a <form> are GET and POST. Svelte allows you to override the <form> method to workaround this limitation if you need to. That way your application can transparently work when JavaScript fails or is disabled by using fetch and <form> interchangeably with the same endpoint.

I like your version of why this feature exists but I'm unsure about removing those 2 bullet points. It should be pointed out that the feature needs to be enabled by the user. The defaults are noted later in the configuration section but they might not notice that. And explaining that the form method must be POST and cannot be overridden with GET will prevent users from using this feature incorrectly and forcing them to figure out what is wrong when they receive build errors or their app doesn't function as expected.

I agree about documenting everything. But for me docs are a last resort (the actual text, anything beyond skimming through code examples) when things already went wrong and I need to figure out why. But we can do much better. During dev when we see _method and methodOverride is disabled we can tell the developer that it needs to be enabled. Same if we see _method with something other than POST. Same for all other cases that are currently silently ignored. If the method is not in allowedMethods arguable it should even return a 400 in production. Or at the very least during dev it should tell you. We have the knowledge, let's not make the user run into unexpected behavior (e.g. silently ignoring _method for GET). Instead let's fail as loud as possible so they don't need to open their browser to actually read the docs or search though /issues. Let them stay in the zone and be like "oh, I need to set enabled: true, gotcha, thanks friendly error message".

Agreed. Can anyone tell me how compile/build warnings are generated in Sveltekit?

And I'm on the fence regarding returning a 400 if the method isn't in allowed methods, but I agree silently ignoring it is probably not the correct action. I'd like to handle it similar to other scenarios in Sveltekit.

documentation/docs/14-configuration.md

packages/kit/src/runtime/server/index.js

Prinzhorn · 2021-12-14T16:32:27Z

documentation/docs/01-routing.md

+Given that the only valid `<form>` methods are GET and POST, functionality is provided to override this limitation and allow the use of other HTTP verbs. This is particularly helpful when ensuring your application works even when javascript fails or is disabled.
+
+- Disabled by default to prevent unintended behavior for those who don't need it
+- For security purposes, the original method on the form must be `POST` and cannot be overridden with `GET`


I don't think we need to be that specific and it's also not just a security thing. GET has vastly different semantics from POST, PUT etc. We should focus on why the feature exist, what problem it solves. I don't see any problem being solved by changing the method from/to GET.

I'd shorten the paragraph and the two bullet points to something like:

In contrast to fetch the only valid methods for a <form> are GET and POST. Svelte allows you to override the <form> method to workaround this limitation if you need to. That way your application can transparently work when JavaScript fails or is disabled by using fetch and <form> interchangeably with the same endpoint.

documentation/docs/01-routing.md

netlify · 2022-01-07T21:05:25Z

❌ Deploy Preview for kit-demo failed.

🔨 Explore the source changes: 4c3b054

🔍 Inspect the deploy log: https://app.netlify.com/sites/kit-demo/deploys/61db386281b2450007c38c32

Rich-Harris

Thanks, this is great.

It's always a good idea to avoid things like 'both', since it's not future-proof — if we decided we wanted to support method overrides via headers, for example (which is sometimes used to get around firewalls that disallow non-GET/POST requests), then 'both' would need to become 'all', which would be a breaking change.

If we implement #70 (comment), we'll no longer be able to read form data before selecting a handler, which means that the hidden input method won't work in future.

What I'd suggest, therefore, is something like the following defaults...

methodOverride: {
  allowed: [],
  header: null,
  parameter: '_method'
}

...which would typically be used like so:

methodOverride: {
  allowed: ['put', 'delete']
}

// or
methodOverride: {
  allowed: ['put', 'delete'],
  header: 'x-http-method-override'
}

enabled is unused here because it's arguably redundant — it's enabled if you specify allowed methods, disabled otherwise.

packages/kit/src/runtime/server/index.js

netlify · 2022-01-11T00:38:56Z

❌ Deploy Preview for kit-demo failed.

🔨 Explore the source changes: e3cdab5

🔍 Inspect the deploy log: https://app.netlify.com/sites/kit-demo/deploys/61dd01a8c38474000773170b

…values

Rich-Harris · 2022-01-11T04:04:07Z

Wonderful, thank you!

brandonleboeuf · 2022-01-16T02:11:43Z

I see that this change has been made in the repo, but they are not present when npm init svelte@next is run.

Getting these errors still

am283721 · 2022-01-16T02:36:30Z

@Rich-Harris @benmccann @ignatiusmb

Edit: Thanks @geoffrich, probably related to the svelt.config.js file in the shared folder

The changeset for this PR includes both the @sveltejs/kit and create-svelte packages, but it looks like the changes to the create-svelte template aren't included when scaffolding a new project a thus the new config settings aren't copied over.

~~Specifically this file: packages/create-svelte/templates/default/svelte.config.js~~

~~I'm new to using changesets, so it may have been something I did wrong. Could you help take a look at this?~~

geoffrich · 2022-01-17T19:12:16Z

@am283721 Thanks for the report, I don't think this is related to the changeset. See the issue I opened above.

Add functionality to override http methods (issue sveltejs#1046)

5252335

See: sveltejs#1046

vercel bot had a problem deploying to Preview December 6, 2021 02:30 Failure

benmccann reviewed Dec 13, 2021

View reviewed changes

documentation/docs/01-routing.md Outdated Show resolved Hide resolved

benmccann reviewed Dec 13, 2021

View reviewed changes

Removing changes to lockfile

d9cb88a

vercel bot had a problem deploying to Preview December 13, 2021 15:02 Failure

Prinzhorn reviewed Dec 14, 2021

View reviewed changes

Validate allowed_methods does not contain GET, rephrase docs

8b4b713

vercel bot had a problem deploying to Preview December 20, 2021 15:47 Failure

merge master -> method-overrides

f9d55b9

vercel bot had a problem deploying to Preview January 7, 2022 21:05 Failure

Rich-Harris requested changes Jan 7, 2022

View reviewed changes

packages/kit/src/runtime/server/index.js Outdated Show resolved Hide resolved

Merge branch 'sveltejs:master' into method-overrides

4c3b054

vercel bot had a problem deploying to Preview January 9, 2022 19:32 Failure

Merge branch 'sveltejs:master' into method-overrides

7ac5c7f

vercel bot deployed to Preview January 11, 2022 00:38 View deployment

am283721 added 2 commits January 10, 2022 19:43

Remove hidden field strategy and enabled config, rename other config …

2c357ae

…values

lint/format

63d9dcb

vercel bot deployed to Preview January 11, 2022 00:46 View deployment

am283721 requested a review from Rich-Harris January 11, 2022 00:55

Rich-Harris added 2 commits January 10, 2022 22:42

tweak error messages

ea1f75e

slim docs down

6ae9e7a

vercel bot deployed to Preview January 11, 2022 03:50 View deployment

Rich-Harris approved these changes Jan 11, 2022

View reviewed changes

tweak changeset

e3cdab5

vercel bot deployed to Preview January 11, 2022 04:03 View deployment

Rich-Harris merged commit 3523d38 into sveltejs:master Jan 11, 2022

github-actions bot mentioned this pull request Jan 11, 2022

Version Packages (next) #3280

Merged

This was referenced Jan 11, 2022

remove accidental export #3281

Merged

Method overrides #1046

Closed

am283721 deleted the method-overrides branch January 11, 2022 13:58

paolodina mentioned this pull request Jan 12, 2022

Temporary issue due to recent SvelteKit change mootoday/sveltekit-prisma#13

Open

geoffrich mentioned this pull request Jan 17, 2022

Freshly-scaffolded demo app does not include methodOverride in svelte.config.js #3385

Closed

benmccann mentioned this pull request Jan 31, 2022

[docs] "What's new in Svelte" February newsletter sveltejs/svelte#7202

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add functionality to override http methods (issue #1046) #2989

Add functionality to override http methods (issue #1046) #2989

am283721 commented Dec 6, 2021

changeset-bot bot commented Dec 6, 2021 •

edited

Loading

benmccann Dec 13, 2021

am283721 Dec 13, 2021

benmccann Dec 13, 2021

am283721 Dec 13, 2021

Prinzhorn Dec 14, 2021

am283721 Dec 15, 2021

Prinzhorn Dec 15, 2021

am283721 Dec 16, 2021

Prinzhorn Dec 14, 2021

netlify bot commented Jan 7, 2022 •

edited

Loading

Rich-Harris left a comment

netlify bot commented Jan 11, 2022 •

edited

Loading

Rich-Harris commented Jan 11, 2022

brandonleboeuf commented Jan 16, 2022

am283721 commented Jan 16, 2022 •

edited

Loading

geoffrich commented Jan 17, 2022

		@@ -30,7 +30,7 @@ importers:
		'@sveltejs/eslint-config': github.com/sveltejs/eslint-config/9a7d728e03ac433e5856a6e06775c17ee986d641_d9525e585486a10ae6317f3f61e9597f

	- For security purposes, the original method on the form must be `POST` and cannot be overridden with `GET`
	- To protect against CSRF attacks, the original method on the form must be `POST` and cannot be overridden with `GET`

Add functionality to override http methods (issue #1046) #2989

Add functionality to override http methods (issue #1046) #2989

Conversation

am283721 commented Dec 6, 2021

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

Tests

Changesets

changeset-bot bot commented Dec 6, 2021 • edited Loading

🦋 Changeset detected

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

netlify bot commented Jan 7, 2022 • edited Loading

Rich-Harris left a comment

Choose a reason for hiding this comment

netlify bot commented Jan 11, 2022 • edited Loading

Rich-Harris commented Jan 11, 2022

brandonleboeuf commented Jan 16, 2022

am283721 commented Jan 16, 2022 • edited Loading

geoffrich commented Jan 17, 2022

changeset-bot bot commented Dec 6, 2021 •

edited

Loading

netlify bot commented Jan 7, 2022 •

edited

Loading

netlify bot commented Jan 11, 2022 •

edited

Loading

am283721 commented Jan 16, 2022 •

edited

Loading