There are actually a number of ways to redirect a browser, both in the HTTP protocol itself, and in the content being served.
  1. A web server can redirect by returning a status code of 301 (moved permanently) or 302 (moved temporarily) instead of 200 (success) or 404 (not found). The browser will generally redirect immediately to the URL given in the Location header.
  2. It can also redirect by returning a Refresh header. This header should contain the amount of time to delay before redirecting, optionally followed by a semicolon and the URL to refresh.
  3. It can put a meta http-equiv tag in HTML content, which has the same effect as the above.
  4. Finally, JavaScript code can change the document.location object to a new url
"http-equiv" in the <meta http-equiv> tag simply allows certain http headers to be encoded directly into HTML. http-equiv="x" content="y" translates to an HTTP header that looks like "x: y". So <meta http-equiv="Refresh" content="3; URL=picturesofmydog.html"> is equivalent to "Refresh: 3; URL=picturesofmydog.html". The whole http-equiv came about to allow web content developers to use client pull straight from their HTML, without mucking around with HTTP.

Server side scripting languages such as ASP or PHP have special commands for redirecting too, but there is nothing special about them. They are short-cuts for using one of the above methods; since these are server side languages, they end up as an HTTP or http-equiv redirect before being sent over the internet.

So are there any situations where it makes sense to put the refresh in the HTTP headers, rather than the HTML? Well, consider the case where there is no HTML. HTTP allows refreshing all types of content, not just HTML. For example, it is possible to have an image within a non-refreshing page refresh itself; this can be used as a crude form of animation. In this case, the http-equiv method would simply be impossible, but the HTTP header still works.