Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
This is more of an observation + general + theory and design + client side topic.
I have been using header('Location: http://www.example.com/page.php') forever, using the post-redirect-get pattern. I've never really used meta refresh tags.
I've sent 10s (if not hundreds) of millions of page views (yes, i'm serious) to these requests and I've never (nope, not once, zero, zip, zilch, nada) had one complaint of not being redirected or anything even related to the nature.
Is the importance of using a meta refresh tag over the header location value even a relevant topic anymore?
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
Ambush Commander wrote:I've never understood why (phpBB included) apps used Meta tags. Maybe to throttle server usage?
Perhaps. It was always my impression that meta refresh was used to avoid header()'s being sent and ignored (along with Location). Maybe I got the wrong reasoning?
Anyhoo all of my web sites use PRG to submit process and display data.
I'm thinking I may have thought there was an issue there when maybe there is not.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
meta-refresh stops double-posting, but header('Location: xxx') doesn't as far as I am aware. I'm only going by hear-say, I haven't even tried to test it.
Jenk wrote:meta-refresh stops double-posting, but header('Location: xxx') doesn't as far as I am aware. I'm only going by hear-say, I haven't even tried to test it.
I use header("Location: X") after form posts and it clears the $_POST and stops double posting. Unless you mean something else.
You probably don't remember it but for a large class of PHP apps in the early 2000s the Location header simply did not work. Whether it was php header screwups or browsers - it's since been fixed. Possibly just a traditional aversion to unreliable Header reliance from bygone years?
The "meta/http-equiv" tag is supposed to provide an alternative mechanism to add HTTP headers to the response - like in situations when you don't have control over the headers, just the contents. Thus, a "refresh" is no different than "location" - both are supposed to work as HTTP headers.
Mordred is spot on. The name "http-equiv" actually means HTTP Equivalent, so they do the same as setting he HTTP header before the HTML. Options are often a good thing, but the question with options is always -- when to use each option?
Here it is a fairly simple choice. If it is better to set the headers in PHP then use header(). An example is redirects. Often when you redirect it is because there is no current "page" and you are transitioning from one to another. Therefore there is no template/view to create the empty HTML response with the meta/http-equiv. Conversely, you may want to give control for setting headers to the HTML side of things. That could be designers or yourself. That can support cleaner separation because you should not let things like redirects leak into your Controllers.
One thing against header().
Some years ago I have to work with Microsoft IIS5 + Php. In this environment all cookies send along with a header() will not be set. From IIS6 there's no cons.
arborint wrote:That can support cleaner separation because you should not let things like redirects leak into your Controllers.
If redirects don't belong in controllers, where do they belong? If I have a controller that handles, say, an edit page, and I post an update to it, I'd want the controller to redirect after sending the updates to the model. Where would you place the redirect?
I think redirects are probably best done in the View. Redirects are a HTTP thing, as opposed to forwards for example which are a Controller thing. That does not mean that Controller could not tell the View "Hey View, do that HTTP redirect thing you do!" As "Web x.0" comes our way there will be more kinds of responses that are not redirectable in the same "page" sense we typically think of, so I think it makes sense (as practical) to push all HTTP stuff into the View.
arborint wrote:I think redirects are probably best done in the View. Redirects are a HTTP thing, as opposed to forwards for example which are a Controller thing. That does not mean that Controller could not tell the View "Hey View, do that HTTP redirect thing you do!" As "Web x.0" comes our way there will be more kinds of responses that are not redirectable in the same "page" sense we typically think of, so I think it makes sense (as practical) to push all HTTP stuff into the View.
I'm confused. What are 'forwards' in this context?
A forward is really an Front / Action Controller concept. Since the Action Controller is dispatched based on the action parameter, some implementations allow you to specify an action parameter to chain an additional Action Controller to run after the dispatched one exits. You can think of it as a programmatic redirect as usually the current Action Controller exits and the next one is dispatched.
The difference IMHO is a "redirect" before, or after the page has been loaded... Meta waits until all html has been loaded, and then starts counting....
And very important, meta redirects are considered a 302 redirect, temporary.... At least by Search Engines...