Refresh - meta or HTTP header?

Someone asked how to do a delayed redirection. They said they were using php, so I told them to use the refresh HTTP header, even though it’s not valid in the RFC 2616 specifications. Then someone else said not to mess with the headers unless you absolutely know what you’re doing. They told me by not using a valid header, some browsers could crash or something like that, and to use the meta tag instead or javascript. So I was wondering, is there really a problem with using the refresh HTTP header? I have tried searching, but I don’t seem to be able to find an rfc specification about the refresh HTTP header…

I don’t personally know of any problem with using header(“Location:…”); other than it can produce error messages if you have some form of output before it is called without using output buffering.

No, not the location HTTP header. That’s fine it’s in RFC2616, I’m talking about refresh:

Refresh: 3; url=http://something.com

or something like that.

Well I found the answer. Thanks anyway…

I’m curious now, what was the answer?

Don’t use the refresh HTTP header because it’s not specified in any of the RFCs. In Safari it won’t do a single thing. Well… you’ll get a white space at the very top of your page. In some other browsers, it can indeed crash.

So instead, if you want a delayed redirection, use either the meta tag or some javascript. And like always, post a link to where the viewer is going to be redirected to so that if all else fails, the user can click on it manually.

Thank you. Luckily that’s what I’ve always done (as it’s how I’ve seen everyone else do it), but your mention of using a header method made me curious, especially since Firefox/Mozilla will not redirect on a META refresh after it uses its RTE engine on any preceeding page during that browser session. (Known bug.)

Can you show me the code you used to test this?

I fully appreciate the desire to treat RFC 2616 as the final word on HTTP, but it’s not quite that simple. SSL is defined elsewhere, cookies are defined elsewhere (and both RFCs describing cookies are not in perfect synchronization with industry support), etc. I wrote a book on HTTP years ago because of this problem - I wanted to try to merge all of the relevant information into a single volume.

Refresh is widely supported, and I’m not aware of any browser that doesn’t support it. It works with Safari 1.3.2 - I don’t have a newer version, because I have to buy the new Mac OS X to get it. :slight_smile: I’m not sure why you say that Safari won’t do a single thing. It makes me wonder if your Refresh header is malformed. Here’s a quick example:

header('Refresh: 0; url=http://www.google.com/');

The http-equiv attribute of the meta tag is just a way to let you specify HTTP headers in the content of the response. This is useful for static resources such as plain HTML files, because you have no direct control over the HTTP headers. For example, you’re able to set things like the Content-Type and Expires headers using this approach.

In PHP, we have the header() function, so we can set real HTTP headers.

By the way, the W3C discourages the use of Refresh to redirect to a different URL. The original intent of the header was to reload the current resource. Also, you might be interested in this:

http://www.hixie.ch/tests/evil/mixed/refresh1.http.html

I haven’t tried it in anything else other than IE, Firefox/Mozilla, and Opera. All of those support the refresh header. My refresh header is not malformed. According to kim at bonfils dot com on the header page at php.net, her comment said that in Safari it had a blank white space at the top, and didn’t work. It could’ve changed since your version. I asked the makers of the acid test of browsers that changed to be more standard, and Safari was one of the three browsers listed. I’ve heard that when certain browsers get a HTTP header they don’t recognize, they can crash.

Yeah, I figured the meta tag did that a while ago. I don’t typically use meta tags. Anyway, I thought the browser would have more control with meta considering it’s not quite as embedded as when using php. It’s kinda hard for me to put this into words… With php, it’s all handle on the server side, and the headers are sent directly to the browser where as with metas the browser still has to interpret them. So with the meta, if the browser doesn’t recognize it, it can just ignore them. Or am I wrong to think this?

Yeah I’ve used that refresh test. I SUed it not too long ago.

The browser interprets the headers either way. The difference is:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 19
Refresh: 0; url=http://www.google.com/

<html>
TEST
</html>

Versus:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 100

<html>
<head><meta http-equiv="Refresh" value="0; url=http://www.google.com/" /></head>
TEST
</html>