Take the 2-minute tour ×

I've built a new site for our company, whom I recently started working for, and deployed it on a separate subdomain (http://site.mysite.com) to not interfere with some URLs that need to remain on the old subdomain.

The old HTML site (http://www.mysite.co/site) was, for some weird reason, placed inside the public/ folder of a Zend application, as public/site. We want to redirect this site, which used to be available on http://mysite.com/site folder, to our new site at http://site.mysite.com

I've edited the existing .htaccess file, inside the Zend public folder so it looks like such:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^mysite.com [NC]
RewriteRule ^(.*)$ http://www.mysite.com/$1 [R=301,NC,L] 

# These four lines are my only alterations to this file...
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^/(apps|site).* [NC]
RewriteRule .* http://site.mysite.com/ [R=301,L]**

RewriteRule ^cart/selectaddress$ https://%{SERVER_NAME}/cart/selectaddress [R,L]

Redirect 301 /photobook-sa http://www.mysite.com/photobooksa/
Redirect 301 /photobook-SA http://www.mysite.com/photobooksa/
Redirect 301 /photobookSA http://www.mysite.com/photobooksa/

RewriteRule ^channel\.html channel\.php

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d [OR]
RewriteCond %{REQUEST_FILENAME} -f 
RewriteRule ^.*$ - [NC,L]

php_value session.auto_start 0
RewriteRule ^.*$ index.php [NC,L]

AddDefaultCharset UTF-8

The idea is to trap http://mysite.com/apps/, http://mysite.com/apps/whatever and http://mysite.com/site/ and redirect these all, unconditionally to http://site.mysite.com

The problem is, the redirection only works for /apps and apps/whatever, not for /site. So I discovered the public/site folder, which strangely hosts the company site as a HTML only site, within a Zend project folder structure.

Problem is, when I delete this folder, the whole mysite.com and www.mysite.com domain fails, but for example mysite.com/apps still manages to redirect to site.mysite.com

So I tried editing public/site/index.php to look as follows:

header('Location: http://site.mysite.com'); exit;

and it works, but only for a few requests, then I get a server error.

I also tried adding a .htaccess inside public/site/.htaccess with the following:

Redirect 301 http://site.mysite.com

which also, works initially, but then fails with a server error after a few requests?

I have no idea what's up, no clue as to why the virtual host is dependant on the public/site folder to work, which not even mentioned in the virtual host setups.

I grepped all the controllers in the Zend application/controllers folder to try and see if I can find anything that remotely mentions this /site folder, but no matches found.

I'm pulling the hair out of my scalp with this strange behaviour, can someone please help?

Also last point, this is an Amason AWS server, which I'm not entirely familiar with, could it be that this server has something funny going on, that's non-standard in terms of Apache configuration, DNS setup or something mysteriously automagic?

share|improve this question
isn't the subfolder a chache'd version of your live site? If php caching etc.. is enabled that could explain it? –  Michael Dibbets Feb 20 '13 at 10:28
Michael, it could be, but when I alter it, the changes reflect immediately, only to fail a few minutes later. –  josef.van.niekerk Feb 20 '13 at 10:37
Do you use these kind of configurations? docs.aws.amazon.com/AmazonS3/latest/dev/… Maybe it's setup somewhere there that a static page should be stored there or something? –  Michael Dibbets Feb 20 '13 at 11:58

1 Answer 1

up vote 0 down vote accepted

We've not been able to resolve this issue, and unable to figure out why our methods work only for a few minutes. I'm suspecting something weird happening with Amazon AWS.

The only way we could fix, was by adding an index.html inside the culprit /site folder, using a small JavaScript snippet to redirect the site from the client side.

share|improve this answer

Your Answer


