Incorrect behavior when server returns redirect.

[slbug]

Example:

I'm on /posts/1 page
there is a link to /posts/1/do_something

in controller

def do_something
  ...
  redirect_to @post
end

When I press this link i see in log file

GET /posts/1/do_something
Redirected to /posts/1

GET /posts/1

GET /posts/1/do_something
Redirected to /posts/1

GET /posts/1

So it do requests twice.

P.S. #260 does not fix problem

[reed]

Are both requests from Turbolinks (AJAX requests)? Or is one of them a full page load?

[slbug]

only last one is full page load.

[reed]

Typically, this would be the result of the JS/CSS assets having changed. Is that the case? (I realize that it's unlikely since they're the same page, but it's not impossible, so I have to ask.)

If not, what browser are you using? (If it's chrome, a version number will help.) Or does it happen on all browsers?

[slbug]

No asset changes. Opera Developer 18.0.1284.2 (Chrome/31.0.1650.4)

[reed]

So does it work on other browsers? If so, could be related to #278. Not sure why it would only be happening on redirects though.

[2called-chaos]

I have the same problem and I only discovered it due to an somewhat edge case "logout" with a sudo/login_as session. I had in mind to redirect the admin back to the backend user page (where he started off with the sudo action). There is a change in the assets but I don't understand why turbolinks doesn't redirect to the already resolved destination:

Since the logout action is visited twice the admin will logged out completely. Usually get requests shouldn't be destructive and I possibly should just add data-no-turbolink to logout links but I still would expect turbolinks to redirect to the already redirected target where the actual asset change happens.

[reed]

@2called-chaos If Turbolinks redirected straight to the already redirected target, then the resulting page would be missing things that are set by the original action, such as flash messages. Like you said, you shouldn't be using GET requests for destructive actions, but if you must for some reason, just use data-no-turbolink.

Closing this since I can't reproduce (without doing something where the double request is by design).