tags:

views:

104

answers:

5

Quick question, I noticed that on some of my header directors I was getting some lag while the header processed. Is using return standard after using headers? Also if you use a header on pages you don't want directly accessed, such as processing pages will return; stop that processing even if the page is not directly accessed? IF return is a good idea would it be better to use exit()?

+7  A: 

header("Location: ......"); exit; is a fairly common pattern.

Amber
-1 for not outputting any body as per recommended by the spec
symcbean
Not sure which spec you're going by, but RFC2616 Section 14 (the part that covers headers) makes no mention of outputting body content. In fact, Section 4 explicitly states "All other responses do include a message-body, although *it MAY be of zero length*."
Amber
+7  A: 

You do not need to supply return; after calling header but I know some people use the convention of supply exit; after header call to ensure the code below will not execute during a redirect.

Anthony Forloney
+3  A: 

Keep in mind you can use header() for other things besides Location: redirects:

header("Content-type: image/jpeg"); // for example

The reason you would exit after a header redirect is, any content output after a header() redirect, will (most likely) not be seen by the browser. More importantly you wouldn't want any code to be executed after a header() redirect, so calling exit() after a redirect is good practice.

deadkarma
+2  A: 

When you send the header, it is but a mere advisory to the client(the browser) that you think they should request another url instead. However, nothing can stop them from not following your recommendation. They can continue reading more data from the current url, if your server keeps feeding it to them. This is why you generally see php code that calls exit() after sending a redirect header, because if you stop outputting more data, there is nothing for them to read.

Aside from keeping them from reading unintended data, there's other reasons:

Maybe it's just plain senseless for the rest of the script to continue executing, wasting resources.

Maybe runtime errors would occur if the script were to continue(ex, there were missing variables, or a db connection failed).

Maybe logic errors would occur if the script were to continue(ex, user input validation/authentication failed).

chris
Thanks, that was informative and useful to me.
Scarface
Would you recommend putting headers on all processing pages? If so wouldn't exit stop the processing? What would you suggest as far as constructing an if statement for the headers for those pages?
Scarface
It's not _required_ to stop script execution immediately after sending a redirect header. You stop execution if its desired, and when it's appropriate.
chris
So basically you are saying, if I want to put headers on a processing page, which are non conditional and only for people who try to access the page directly, the I do not need exit...right?
Scarface
+1  A: 

It's up to the client to determine what to do after an header("Location: ...").

Any code after header() will be executed regardless. Putting an exit(); just after the header is a safeguard and is required for securing your site.

If you have some candy after header("Location: ..."), the only thing the browser have to do is to ignore the request. Then it'll be clear as day. With exit(); you're stopping execution of the page and hopefully there are no other attack vectors to your app!

Kent