collimarco
January 17, 2022, 11:58am
1
It seems that Turbo does not handle 302 properly. You need to use 303 instead.
This breaks all existing applications, all redirect_to needs to be changed, Devise and other gems are broken…
Is it a Turbo bug that will be fixed? Otherwise, why this breaking change!?
Isn’t it better to handle the 302 normally as in the past?
1 Like
No idea why they made the change, but there’s an upgrade guide for existing apps that handles redirect properly:
# Upgrading from Rails UJS / Turbolinks to Turbo
Turbo supersedes the functionality offered by Rails UJS to turn links and form submissions into XMLHttpRequests, so if you're making a complete switch from Rails UJS / Turbolinks to Turbo, you should ensure that you have `config.action_view.form_with_generates_remote_forms = false` set in your `config/application.rb`. But not all applications can upgrade in one jump, and may need to have Rails UJS coexist alongside Turbo. Here are the steps you need to follow:
## 1. Ensure Rails UJS is using compatible selectors
Rails UJS is offered either directly from the Rails framework or by the classic jquery-ujs plugin. Whichever of these you use, you can leave in place, but you need to either upgrade to a compatible version (see https://github.com/rails/rails/pull/42476) or vendor the JavaScript file needed in your app and tweak it yourself.
## 2. Replace the turbolinks gem in Gemfile with turbo-rails
You no longer want `gem 'turbolinks'` in your Gemfile, but instead `gem 'turbo-rails'`. But in order to have Turbo work with the old-style XMLHttpRequests issued by UJS, you'll need to shim the old Turbolinks behavior that made those requests compatible with 302s (by invoking Turbolinks, now Turbo, directly).
First you need to add `app/controllers/concerns/turbo/redirection.rb`, which should be included in `ApplicationController` as `Turbo::Redirection`:
```ruby
module Turbo
module Redirection
extend ActiveSupport::Concern
def redirect_to(url = {}, options = {})
turbo = options.delete(:turbo)
show original
1 Like
t27duck
January 17, 2022, 2:45pm
3
I believe it has to do with Turbo using the fetch API under the hood for all of its requests. The spec for how the fetch API works responds to 302s differently if they are not GET or POST requests.
The discussion here outlines what is happening:
opened 01:26PM - 07 Jan 21 UTC
closed 03:34PM - 07 Jan 21 UTC
According to documentation:
https://turbo.hotwire.dev/handbook/drive#redirect… ing-after-a-form-submission
> After a stateful request from a form submission, Turbo Drive expects the server to return an HTTP 303 redirect response, which it will then follow and use to navigate and update the page without reloading.
It appears that Turbo works fine with any 3xx code (e.g. 301 or 302). However is this going to be a hard rule? Many non-Rails frameworks (e.g. Django) assume a 301 or 302 redirect by default, and this will break standard behavior. Is there a good reason for this or should the docs be updated?
1 Like
Mark9322
February 14, 2022, 7:09am
4
Facing same Issue. Did you find any solution.
drewlee
February 27, 2022, 3:50pm
5
I think there are a few possible solutions:
Convert it to a button
Handle turbo in format.turbo_stream
Return a 303 or :see_other in the redirect
Look at seanpdoyle’s messages in this thread https://github.com/hotwired/turbo-rails/issues/301
1 Like