pages ignore HTTP method -- is this desirable?

[kamholz]

I recently noticed that SvelteKit matches pages on path alone and ignores the HTTP method. For example, if you create routes/foo.svelte, you can GET, POST, PUT, or DELETE to /foo and the rendered response is the same. This may be intentional, but it's pretty surprising, so it should at least be documented.

One complication of the current implementation is that the HTTP method and request body (for example POSTed form data) are not made visible to load. They're available in handle, so someone could pass them along via context pretty easily if they wanted to. On the other hand, if someone wants to globally restrict pages to GET only (which seems sensible for many use cases), I don't see an easy way to do that currently, because handle doesn't know if it's going to render a page or an endpoint.

I'm creating this issue to bring attention to this (unintentional?) design feature and start more discussion about it. I don't really have a strong opinion on how to address it other than to document it better. And it would be nice if load had more visibility into the request without needing custom code in handle. (It would also be possible to fix things by only matching pages on GET, but that's probably unnecessarily restrictive.)

[Rich-Harris]

Yeah, I think pages themselves should only respond to GET requests. In cases where you do want to POST to /some-page, it's easy enough to have a /some-page.js endpoint that handles the POST then falls through (by not returning anything) to /some-page.svelte

[kamholz]

That seems reasonable but it does prevent you from easily using the classic <form method="POST"> to the same URL that renders the form. But maybe that's fine, since there are more modern alternatives with endpoints etc.

[Rich-Harris]

It doesn't — /some-page.svelte can POST to /some-page.js, which falls through to /some-page.svelte

[Rich-Harris]

Ah, I guess you were responding to this:

Yeah, I think pages themselves should only respond to GET requests

Now that I think about it, I think we looked into this before and decided that the current behaviour does make sense, because if pages did only respond to GET requests then the fall-through wouldn't work (unless we changed the method mid-response, which would be rather odd).

The weirdness that results is that you can also POST (or any other verb) to a page that isn't shadowed by an endpoint, but that felt like an acceptable tradeoff.

[kamholz]

Now that I think about it, I think we looked into this before and decided that the current behaviour does make sense, because if pages did only respond to GET requests then the fall-through wouldn't work (unless we changed the method mid-response, which would be rather odd).

Would it be possible to restrict page handling of non-GET requests to fallthrough cases? I guess there isn't currently a way because fallthrough is purely negative (lack of a response) and there isn't really a way to detect whether an endpoint did something and wants/expects fallthrough. However a partial version of this might be possible, where pages that lack shadow endpoints only take GET.

[Rich-Harris]

It veers slightly into magical territory. I think I'd prefer that we just document that pages will respond to any method, and if you want to handle non-GETs sensibly then you need a shadowing endpoint with a fallthrough

[goynang]

Sorry to tack a question on to this but... when you do fall through is it possible to access data that was created in the endpoint? How about the original request body?

My use case example being an endpoint that processes a form submission (POST), checks for validation errors and, if there are any, falls-through to re-show the form with the errors displayed (and originally posted values) so the user can try again. i.e. the "the classic

" approach mentioned above.

[Conduitry]

@goynang Take a look at #1711.

[Rich-Harris]

Closing in favour of #3532