Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirect to new page on successful form submission contains unexpected text/vnd.turbo-stream.html #1018

Open
pySilver opened this issue Oct 3, 2023 · 4 comments

Comments

@pySilver
Copy link

pySilver commented Oct 3, 2023

I'm surprised to see that form POST submission that responded with a redirect results in following this redirect along with text/vnd.turbo-stream.html header attached.

Is that a bug or desired behavior? It is really hard to distinguish such redirects from other stream requests on the backend. I believe it's a bug because if I wanted to respond with a stream I'd do it directly, instead of sending a redirect header.

Am I missing something?

@seanpdoyle
Copy link
Contributor

@pySilver how was the original POST request submitted? Was it through a <form> element submission or a fetch request?

What is the status code in the response from the server? Is it a 303 See Other like the Turbo Drive documentation suggests, or another 3xx code?

The 303 See Other redirect would result in a subsequent GET request, whereas other status codes would use the request's verb (in this case, a POST).

@pySilver
Copy link
Author

@seanpdoyle Sorry for the delay with the reply. Setup was the following:

  1. POST form with various input fields. Form is not nested in a frame.
  2. Backend endpoint that consumes data and returns 302/303 redirect (does not matter) to some location within the same domain and protocol (actually it's localhost at the moment).

What I've expected: The user is redirected to a new location using GET request without any specific request headers attached.
Observed behavior: The user is redirected -//- but Turbo accept header is being repeated for final location.

@seanpdoyle
Copy link
Contributor

@pySilver thank you for clarifying!

I believe that the client-side of Turbo doesn't have access to the intermediate redirect response headers, so it doesn't have access to remove the header.

@pySilver
Copy link
Author

@seanpdoyle Yeah. This is what I thought - it's probably the browser that is following a redirect and applying previous headers automatically (or more specifically Fetch API). I'm wondering: How it differ when the form is wrapped in the frame?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants