Forum Moderators: phranque
If it is a brand new site, build a minisite to at least show people who you are and what you will be doing, and get that indexed, while you test the real site in a password protected dev subdomain.
The correct response for a site that is offline is to return '503'.
Content returning 200 will be indexed.
4xx error messages are usually not a good idea in this context.
ErrorDocument 503 /error_503/index.php
Thanks in advance.
what is the command to have all visitors during a period of temporary maintenance see the 503 page?
ErrorDocument 503 /error_503/index.php
RedirectMatch 503 ^(?!/error_503/index\.php)
Any ideas?
When you get the 500-Server Error, what do you see in the server error log?
Jim
So, the challenge here is to find a way to return 503-Unavailable for any request except for your custom 503 error page... Probably using <FilesMatch>, and possibly requiring you to rename your error page (and any files it includes) to have a unique filetype. This would be a bit easier if it was a static page instead of using php, but I'll have to think about it...
Jim
.htaccess:
RewriteCond %{REMOTE_ADDR} ^123\.123\.123\.123
RewriteRule .* /temp.php [L]
<?php @header("HTTP/1.1 503 Service Temporarily Unavailable"); ?>
<!DOCTYPE HTML ...
(completely untested, but you get the idea)
Not elegant, but simple and should work no matter what version of anything you are running.
use .htaccess to redirect all calls except from your ip to temp.php
This however means that the requested URL does not return the correct 503 response.
Instead it returns a 301 response, and then only after the client has made a new request for a different URL, does the client get the required 503 response.
That situation does not allow the server to directly return a 503 response for the originally requested URL, and the method is therefore flawed.
However, a real problem, if this code is to go into .htaccess, is that the /temp.php file itself must be excluded from the rewrite rule (using a negative pattern in a RewriteCond or in the RewriteRule itself).
Jim
I am running Apache 1.3.41 (Unix), couldn't find anything in the logs though?
Feature development for apache 1.3 stopped several years ago. Of course, you can still use it as you can still run windows 2000 but if you'd like to use new features (Redirect <anystatus> is a new feature since version 2.2) instead of reinventing the wheel, you should consider to upgrade.
Upgrading issues are addressed at
[httpd.apache.org...]
[httpd.apache.org...]
what alternatives do I have with the 503 issue?
Hi, I am looking for a command to temporarily set via a .htaccess file, my site to being under construction. Does a commmand like this exist? Is it possible to set an entire domain under construction this way?
Yes. The following seems to be the closest to correct so far:
How about
* use .htaccess to redirect all calls except from your ip to temp.php
* temp.php throws a header of 503 and shows a pretty 'we're coming!' page?.htaccess:
RewriteCond %{REMOTE_ADDR} ^123\.123\.123\.123
RewriteRule .* /temp.php [L]temp.php:
<?php @header("HTTP/1.1 503 Service Temporarily Unavailable"); ?>
<!DOCTYPE HTML ...(completely untested, but you get the idea)
Not elegant, but simple and should work no matter what version of anything you are running.
But I don't know why you would redirect (or rewrite) everything, except with a 307 TO the index page, since G-bot is an HTTP/1.1 user-agent and will not cache the redirect to the home page if you do not set an expires or cache-control header, will only cache the redirect for the period of time before it is set to 'expire' and will also continue to request the original location on subsequent visits, rather than requesting the new location.
307 Temporary RedirectThe 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.
[w3.org...]
If you chose to redirect you could use the FireFox User-Agent Switcher* a bit creatively while you develop 'behind the scenes' and set your user-agent to some unique string EG 'Site_Reconstruction_Team' with the following in Mod_Rewrite in your .htaccess file:
RewriteCond %{HTTP_USER_AGENT} !^Site_Reconstruction_Team$
RewriteRule !^(index\.php)?$ http://www.example.com/ [R=307,L]The preceding will redirect any user-agent, except Site_Reconstruction_Team, *temporarily* to the home page.
You then can put the following at the top of the home page (or all pages if you choose to not redirect) and everything will load the way it should, except you tell SE spiders to not cache any page it resides on and retry after N seconds. (You must set a retry-after header or the request will be handled as a 500, per the documentation. (See Below))
<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Retry-After: SECONDS");?>
503 Service UnavailableThe server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
[w3.org...]
* You can actually change most browser's user-agent string, but it's easiest with FireFox.
Just my .02 on the situation anyway...
RewriteCond %{HTTP_USER_AGENT} !^Site_Reconstruction_Team$
RewriteRule !^(index\.php)?$ /index.php [L]
/* At the top of index.php */
<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Retry-After: SECONDS");
?>
But personally, I would opt for redirecting using a 307, rather than rewriting... Even if some might think it's incorrect, because the initial server response is 307, not a 503. It's just what I would do and either solution should work. (I have successfully used 307's before, but your results may vary.) I Do Not recommend using a 301, because it's a permanent redirect and says something different to SEs, but my solution is effectively the same as leadegroot's, except with mine everyone lands on the home page and receives the message, rather than an internal page, and if I have the choice of providing a 'hey were doing something page' when someone clicks on an internal URL I would rather redirect them...
It gives me a really cool opportunity to be a bit creative and I might even add a Query_String to the redirect (or set a cookie when they land), so I know if they came from an internal page and show those people a slightly different page, with something like, 'Hey, we brought you here to our home page while we are building a whole new site for you... The page you tried to visit should be available again shortly. Please bookmark this page where we will be publishing our status reports and updates by clicking here, and bookmark the page you initially tried to visit by clicking here, then check back regularly to see our progress! Here's some of the new features we're working on for you...'
Anyway, that's pretty much the reasoning behind why I would redirect to the home page over just rewriting. But that's just me and my newest sites are AJAX and unspiderable, so I'm half off to start with, but hope it gives you some ideas anyway.
So if the plan is not to have the new site ready by tomorrow noon, then the old site should be left on-line until the new site is ready and has been tested on a separate server. Then switch over all at once, using the 503 (if necessary) only during the time required to duplicate the database from the old site over to the new site.
Jim
Obviously, current traffic is not that important (if there is any), or the OP would not want to take it off line at all, but I would probably try to catch the interest of a couple people and pick up a couple bookmarks, which is way more than would be received with the 'make sure they can run away fast' method, because if you don't at least try to tell them what's going on and they visit a couple times 'your site is always broken'.
Retry-After header specifies time in seconds, and that should be taken as a clue that 503s should last for hours at most, not days
Using the same logic everything on a site should 'expire' within hours at the most too, not days or months, like JS, images, CSS files, etc. correct? (I'm really not sure I'm understanding your logic here, when just about all 'times' are set in seconds, including expires headers, cache-control's max-age, php times, etc. We usually agree, but I'm boggled by your statement on this one.)
Would I personally ever put an entire site 'under construction'? The only reasons I can think of are: if I was building it and started with the home page and added the redirects as pages were added, but inner pages would be unlinked and therefore most likely unused. Or, as far as taking a current site off line and purposely serving a 503 site wide if there is traffic? If I was changing the topic of a low traffic, currently non-monetized website and wanted to try to pick up some of the visitors from the current topic and get them interested in the new one, I might especially if the site was an eye-sore and I had something 'cool' to replace it with.
It is, however, a good idea to work out how to do a 503 and to have that infrastructure in-place, ready to be 'switched on' if there is any possibility that it might become necessary to do a database restoral, update, or equalization at any time in the future -- that is, the site is dynamic and relies on a database. That's really the only circumstance that I can think of that justifies a 503, because you can't have users changing the database while it is being restored/updated/equalized, and this process might feasibly take a few hours, rather than just seconds.
Jim
Thanks for the clarification. I probably came across a bit terse in my reply, but didn't mean it that way... My apologies. Sometimes I come across shorter than I intend when typing. (It's one of those fault thingies.)
