Redirect_to doesn't stop rest of page processing?

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

On Jun 27, 11:06 pm, Greg W. [email protected] 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

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

On Jun 27, 11:06 pm, Greg W. [email protected] 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