Timed Redirect

[blm126]

I am trying to achieve that "timed redirect" you see on a lot of forums. They normally use it right after someones post. It says something like "Your browser should redirect you in 10 seconds,if it does not click here". Any help in figuring out how this is done would be appreciated.

[shachi]

Don't know about others but you can achieve this with javascript pretty easily. Here's the code.



function redirect(){
window.location.href = "http://somesite.somedomain/";
}
window.onload = setTimeout("redirect()", 10000);


Redirects browser after 10 seconds.

Hope that helps.:)

[Twey]

A meta refresh is more reliable.
<meta http-equiv="refresh" content="10;url=http://www.example.com/page2.html">

[shachi]

Oh yes I forgot about that. Yes meta is more reliable than javascript because even if the user has javascript disabled meta can redirect you.

[Twey]

However, not all browsers support it. Use both to maximise the chance that one will be supported.
And that Javascript function would be better written as:
setTimeout(function(){window.location.replace("http://www.example.com/page2.html";}, 10000);

[blm126]

Thank you both, now about the meta refresh. Could that also be done with a header?

[Twey]

Apparently so. No idea what the compatibility is though.
<?php $url = 'http://www.example.com/page2.html'; $timeout = 10; ?>

<?php header('Refresh: ' . $timeout . ';url=' . $url); ?>
<meta http-equiv="refresh" content="<?php echo($timeout) ?>;url=<?php echo($url); ?>">
<script type="text/javascript">
setTimeout(function(){window.location.replace("<?php echo($url); ?>";}, <?php echo($timeout * 1000); ?>);
</script>One of those has got to do it. :p

[blm126]

One of those has got to do it. :p
Probably not in IE, it will manage to find some way not to work...
Anyway, I'm gonna do some tests with the header and find out. :)

[blm126]

Ok, I did a little research and testing. Sending a Refresh header appears to work in the latest releases of IE,Firefox,and Opera. However, it is not (an official) part of HTTP and should not really be relied on. I am willing to risk just sending the header and providing a link backup. Hers's my test code if your interested.


<?php
header('Refresh: 1;url=http://www.google.com');
?>

Note: I also discovered that the counting begins once the content is fully loaded in the browser.

[Twey]

Oh, aye. I forgot about the link backup.

Well, so long as you've got that, I wouldn't worry about it too much.

[blm126]

I was bored :)

[mwinter]

I am trying to achieve that "timed redirect" you see on a lot of forums.

Can I ask why? Forums shouldn't do it at all, nor should many other Web applications. Upon successful login, they should issue a temporary redirect (307), set cookies (if necessary), and go straight to the destination.

Logging in successfully is not an exceptional case and doesn't deserve a separate page, especially as it might necessitate explicit action from the user should scripting or meta refreshes be disabled. Simply arriving at the destination is indication enough.

Mike

[blm126]

Can I ask why? Forums shouldn't do it at all, nor should many other Web applications.
Sure,I'm attempting to write a simple CMS(for my own use). I would like to use it in the admin center to provide extra choices. Say for instance the user creates a page. A page would show saying something like "Your browser should redirect you to the admin panel shortly, if not click here to go there now. You may also click here to view the new page.". It is not necessary but could streamline(At least I think so) the admin panel.


Upon successful login, they should issue a temporary redirect (307)

How do you do that? I know how(in PHP) to redirect to a new location like this.


<?php
header('Location: http://somesite');
?>

The PHP manual says that that will also send a 302 header. What is the difference between 302 and 307?

[Twey]

302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.This one always makes me laugh:
410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.... and this one makes me seriously worry about the state of the Web after HTTP2.0 comes out:
402 Payment Required

This code is reserved for future use.

[blm126]

Thanks Twey, but I still don't quite understand. I read through them, but they appear to say almost the exact same thing. What's the difference, or are they interchangeable?

[mwinter]

First of all, I was mistaken: 303 (See Other) would be the correct response, not 307 (Temporary Redirect).



I read through them, but they appear to say almost the exact same thing. What's the difference, or are they interchangeable?

The difference is in the note that accompanies 302 (Found).

The response code originated in HTTP/1.0, and it meant for a request to be repeated using a different request URI, but that the user had to asked to confirm it. Unfortunately, many user agents didn't do either: requests were converted to GET requests (rather than repeated as the same type), and the user was never asked to confirm the redirection.

In HTTP/1.1, 303 (See Other) and 307 (Temporary Redirect) were introduced, and 302 (Found) was redefined. See Other became a formalised version of the badly implemented Found: requests are converted to GET, and the redirection is transparent to the user. Found was changed to be like See Other (convert to GET), except that the mandatory confirmation was retained. Finally, Temporary Redirect became the original 302: requests are repeated (not converted), and confirmation is required.

Alan Flavell has written about this in an article called Redirect in response to POST transaction (http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html).


As the forum-like process is a transition from a POST request (the login) to some final destination (made using a GET request), 303 See Other is the right way to do it.

Mike

[blm126]

Ok, just to make sure I understand. This is what I should do to redirect correctly in PHP.


<?php
header('HTTP/1.1 303 See Other');
header('Location: http://somefile');
?>

[mwinter]

Ok, just to make sure I understand. This is what I should do to redirect correctly in PHP.


<?php
header('HTTP/1.1 303 See Other');
header('Location: http://somefile');
?>


Or (in PHP 4.3.0 or later):



header('Location: <absolute-URI>', true, 303);

which is effectively the same thing. You should also follow the specification's SHOULD statement and include a link as content in the response. Though there are relatively few HTTP/1.0 clients left (NN4 is one of them), it's still a good thing to do.




This one always makes me laugh:


410 Gone

...


Errm, why? :confused:

Joking aside, the 410 (Gone) status could actually be useful if it was convenient to use. The typical 404 (Not Found) response implies that there was something wrong with the request; that the URI was wrong, somehow. This is misleading if the URI was right, but the content has been removed (if it's been moved, a 301 (Moved Permanently) redirect should be set up), and this is where 410 would be handy. The user can know for certain that whatever they were looking for can't be found at that site, and they should go elsewhere.

Mike

[Twey]

I understand that. It's just a little abrupt. I guess my sense of humour is slightly odd. :)

[blm126]

This is really interesting. Does anyone know of any good resources to learn more about this? I have found the w3 specs, but I'm looking for a list of what different browsers support. I have never really spent the time to learn that much about http, and now that I am I see a lot of interesting things you can do with it.For example the 204 No Content and 205 Reset Contents status codes look useful.

[mwinter]

I have found the w3 specs,

The W3C? They don't publish HTTP specifications. That's down to the Internet Engineering Task Force (http://www.ietf.org/) (IETF) through the Request For Comments (http://www.rfc-editor.org/) (RFC) document series, though some of the same people are involved. The W3C do have links and copies of some of the relevant RFCs, though.



but I'm looking for a list of what different browsers support.

I don't know of any such lists, but HTTP is vast. Moreover, it's a network protocol, so it's not just browsers that are significant: there may be any number of intermediate HTTP client/servers along a particular route, acting as proxies or caches, and their behaviour is important, too. I'd be more interested to know about those, and if they're that (or at all) prevelant.

It might be possible to check "manually" using OPTION and TRACE requests, and the Max-Forwards header in a similar fashion to trace route programs.

In all, though, client behaviour is reasonably good. There are some issues with caching (some of which can be read about in RFC 3143), redirection (see the link to Alan Flavell's article in a previous post), and Content-Type header handling (notably that some browsers try to second-guess the value), but following the specification unconditionally (see the definition in 1.2 Requirements in RFC 2616) should help avoid a lot of problems.

Of all browsers, I should think that MSIE is the most badly behaved, so if you get something behaving properly with it, you shouldn't have trouble elsewhere.



I have never really spent the time to learn that much about http,

If you do, or plan to control server behaviour with server-side languages, then in my opinion, knowledge of HTTP (preferably both 1.0 [RFC 1945] and 1.1) is a must. Ignorance of it can mean that you cause the server to behave badly. It's also the cause of programming by mystical incantation: people not understanding how things work, so they try all manner of convoluted schemes in an attempt to hack out the desired behaviour.



... I see a lot of interesting things you can do with it.For example the 204 No Content and 205 Reset Contents status codes look useful.

I don't remember how well-supported 205 is, but you should be careful with both: when a user submits a form (the most likely time you'd use either in a response), it may not be obvious to them that the submission succeeded as nothing visual (or at least very little) will change. However, 204 is useful with back-end code (including AJAX) to indicate success when there's no entity to return.




[On the usefulness of 410 Gone] I understand that.

I know you do. It was some general musing on my part (though I'm sure I've written the same previously). :)

Mike

[blm126]

The W3C? They don't publish HTTP specifications. That's down to the Internet Engineering Task Force (http://www.ietf.org/) (IETF) through the Request For Comments (http://www.rfc-editor.org/) (RFC) document series, though some of the same people are involved. The W3C do have links and copies of some of the relevant RFCs, though.

My mistake, I was doing a search on google and w3.org came up. I should try not to make hasty assumptions like that. :)

[blm126]

Sorry for the double post

I don't remember how well-supported 205 is, but you should be careful with both: when a user submits a form (the most likely time you'd use either in a response), it may not be obvious to them that the submission succeeded as nothing visual (or at least very little) will change. However, 204 is useful with back-end code (including AJAX) to indicate success when there's no entity to return.
I was unable to find any compatibility test results, so I decided to devise my own. From what it is looking like firefox supports 204 but treats 205 like 204. Opera treats both like 200, just like IE. I was wondering if you could confirm that this is a good test?


<html>
<head>
<title>205 and 204 test</title>
</head>
<body>
<form action="205.php" method="get">
205
<input type="text" name="test">
<input type="submit" name="sub">
</form>
204
<form action="205.php" method="get">
<input type="text" name="test">
<input type="submit" name="sub">
</form>
</body>
</html>

205.php


<?php
header('HTTP/1.1 205 Reset Content');
?>

204.php


<?php
header('HTTP/1.1 204 No Content');
?>

[mwinter]

From what it is looking like firefox supports 204 but treats 205 like 204.

I would agree with that...



Opera treats both like 200, just like IE.

...but you've drawn the wrong conclusion, here. Both support 204, but don't understand 205. If the 205 response had an entity, they would display it (so it is like 200 in that sense), but as such a response cannot, that detail is irrelevant.



I was wondering if you could confirm that this is a good test? ...

It gets the job done, though I wouldn't (and didn't) use separate files.

Mike

[blm126]

Well, thanks for all your help. I am going to continue learning (and experimenting) with HTTP. :)

[terrys]

Hi,
I have tried your code, in my site (not yet running) but with problems, Where is the code placed into my code ? I have tried above the footer and also at the beginning of the body.. In fact I had to scrap the page and replace with a copy, (lucky me)
I'm a total beginner with java and php.

[jscheuer1]

PHP headers have to be sent before any content is written to the page. An HTML <meta refresh tag should be one of the first things in the head of the page. A javascript that sets a timeout to change the page can go just about anywhere.

If your host supports PHP, that should be all you need, works in all browsers.

If you're still having problems, show us your code.

[sean456]

Do I use both Java with PHP or the only PHP code is sufficient for the redirect. It getting some confusion

[Beverleyh]

(JavaScript, not Java - Java is something different)

If you can use php, use only the php redirect - that's the most reliable/fastest option.

If you can't use php, use both the JavaScript and meta tag redirect.

[jscheuer1]

Java and javascript are two different things. Java is a server side language, javascript is client side.

There is no Java involved here. However, it could be used. What we are talking about in this thread are PHP, HTML, and javascript. Anything that can send a header to the browser, or otherwise trigger a redirect for it can be used to try to do this. Java can send headers. However, in this case it would be overkill. Unless the page is already Java based, there's no sense in using it just for this.

Javascript and HTML are client based - rely solely upon the user's browser in order to perform. Some browsers can turn off the HTML based meta tag redirects, all can turn off javascript, which would disable any javascript timeout redirect. Only something server side, like PHP can send a redirect to the browser that it cannot, at least not under most circumstances, ignore.

But the whole point of having a message like:


Your specified action is being performed. Your browser will be redirected in a few moments. If not, click here.

that's linked to the desired page, is just in case the redirect doesn't work.

And, as I previously stated, if PHP is available on your host, it's all that you need. But, also as previously stated, it's redirect header must come before anything is written to the page.