From a981bea52d33e8445583855214b8a3d083335afd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Janko=20Marohni=C4=87?= Date: Wed, 12 Jun 2024 10:54:18 +0200 Subject: [PATCH] Update 422 status name to "Unprocessable Content" See https://github.com/hotwired/turbo/pull/1277. --- _source/handbook/02_drive.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_source/handbook/02_drive.md b/_source/handbook/02_drive.md index 6fb5c1d..d3df7e1 100644 --- a/_source/handbook/02_drive.md +++ b/_source/handbook/02_drive.md @@ -318,7 +318,7 @@ addEventListener("turbo:submit-start", ({ target }) => { After a stateful request from a form submission, Turbo Drive expects the server to return an [HTTP 303 redirect response](https://en.wikipedia.org/wiki/HTTP_303), which it will then follow and use to navigate and update the page without reloading. -The exception to this rule is when the response is rendered with either a 4xx or 5xx status code. This allows form validation errors to be rendered by having the server respond with `422 Unprocessable Entity` and a broken server to display a "Something Went Wrong" screen on a `500 Internal Server Error`. +The exception to this rule is when the response is rendered with either a 4xx or 5xx status code. This allows form validation errors to be rendered by having the server respond with `422 Unprocessable Content` and a broken server to display a "Something Went Wrong" screen on a `500 Internal Server Error`. The reason Turbo doesn't allow regular rendering on 200's from POST requests is that browsers have built-in behavior for dealing with reloads on POST visits where they present a "Are you sure you want to submit this form again?" dialogue that Turbo can't replicate. Instead, Turbo will stay on the current URL upon a form submission that tries to render, rather than change it to the form action, since a reload would then issue a GET against that action URL, which may not even exist.