# Redirect\_to doesn't stop rest of page processing?

**URL:** <https://www.ruby-forum.com/t/redirect-to-doesnt-stop-rest-of-page-processing/141631>\
**Category:** Rails\
**Created:** [June 28, 2008, 12:07am UTC](https://www.ruby-forum.com/t/redirect-to-doesnt-stop-rest-of-page-processing/141631 "2008-06-28T00:07:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\
**Post date:** [June 28, 2008, 12:07am UTC](https://www.ruby-forum.com/t/redirect-to-doesnt-stop-rest-of-page-processing/141631/1 "2008-06-28T00:07:51Z")

</div>

I’ve checked my books, google, API… I don’t get it. A redirect\_to  
doesn’t really start a wholly new request. Code after a redirect\_to  
still gets processed. The original request code isn’t terminated.

A) what’s the sense in that?  
B) how prevent it?

Example code causing me problem is below…

– gw

application.rb

before\_filter :initialize\_response

def initialize\_response  
init\_this  
init\_that  
check\_session\_not\_expired

```
 # processing continues here even if
 # check_session_not_expired invokes the redirect_to

```

end

def check\_session\_not\_expired  
if (params[:controller] != ‘login’) &&  
(!@current\_user.login\_is\_valid? || !self.session\_valid?)

```
    flash[:session_expired] = true
    redirect_to(:controller => :login, :action => :login)

```

end

def session\_valid?  
# do stuff  
# return true or false  
end

---

<div class="post-metadata">

**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\
**Post date:** [June 28, 2008, 12:23am UTC](https://www.ruby-forum.com/t/redirect-to-doesnt-stop-rest-of-page-processing/141631/2 "2008-06-28T00:23:03Z")

</div>

On Jun 27, 11:06 pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I’ve checked my books, google, API… I don’t get it. A redirect\_to  
> doesn’t really start a wholly new request. Code after a redirect\_to  
> still gets processed. The original request code isn’t terminated.
> 
> A) what’s the sense in that?  
> B) how prevent it?

redirect\_to is just a function. it would be a big magic if it could  
interrupt the flow of code if you want to you can always return after  
the redirect.  
In this particular case I’d put you check\_session\_nit\_expired in a  
before\_filter (redirecting does stop the filter chain). This is  
usually mentioned pretty explicitly in tutorials etc…

Fred

---

<div class="post-metadata">

**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\
**Post date:** [June 28, 2008, 1:34am UTC](https://www.ruby-forum.com/t/redirect-to-doesnt-stop-rest-of-page-processing/141631/3 "2008-06-28T01:34:59Z")

</div>

On Jun 27, 2008, at 3:22 PM, Frederick C. wrote:

> On Jun 27, 11:06 pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > I’ve checked my books, google, API… I don’t get it. A redirect\_to  
> > doesn’t really start a wholly new request. Code after a redirect\_to  
> > still gets processed. The original request code isn’t terminated.
> > 
> > A) what’s the sense in that?  
> > B) how prevent it?
> 
> redirect\_to is just a function. it would be a big magic if it could  
> interrupt the flow of code

Hmmm. A simple Ruby abort command would do. In my previous Lasso  
life, a redirect including aborting the current request. In old  
versions we had to add the abort command manually after the redirect,  
but recent versions of the language finally added the abort  
internally, and made it a param option to not abort which was a much  
more logical way to go. Doesn’t seem that magical to me.

> if you want to you can always return after the redirect.

sure, but that doesn’t stop the processing from continuing in the  
previous method which called the current one having the rediect –  
which was the scenario I painted.

> In this particular case I’d put you check\_session\_nit\_expired in a  
> before\_filter (redirecting does stop the filter chain). This is  
> usually mentioned pretty explicitly in tutorials etc…

I’ve juggled some things, but still not getting what I want. Looks  
like I have to reorganize quite a bit. I was counting on that  
redirect killing off the current request.

Seems I’ve just gotten “lucky” until now.

– gw