WordPress MU Cloudfront. Trailing slash redirect goes to wrong domain

2 Views

I’m having some trouble with redirects within wordpress redirection causing the domain to change.

Example:
Site – noncdn.somedomain.com
CDN URL – www.domain.com

Read More

When I open links w/o a trailing slash there is a 301 redirect:
Going here: www.domain.com/page
Takes you here: noncdn.somedomain.com/page/

Since Cloudfront is hitting the server using Origin Domain, the server doesn’t even know that requests are coming in from a different domain.

How do I force this 301 to use FQDN w/ correct CDN domain instead of doing a relative redirect?

I’ve already added this so that links on the site and images all load from Cloudfront domain, but it seems to have no effect on the redirect behavior: 

    add_filter('home_url','home_url_cdn',10,2);

function home_url_cdn( $path = '', $scheme = null ) {
    return get_home_url_cdn( null, $path, $scheme );
}

function get_home_url_cdn( $blog_id = null, $path = '', $scheme = null ) {  
    $cdn_url = get_option('home');
    if(get_option('bapi_site_cdn_domain')){
        $cdn_url = get_option('bapi_site_cdn_domain');
    }
    $home_url = str_replace(get_option('home'),$cdn_url,$path);
    //echo $home_url; 

    return $home_url;
}

Any Help is much appreciated!

Thanks!

Post Views: 2

Related posts

Leave a Reply

2 comments

  1. I was tracking down a very similar issue for a while with a Cloudfront distribution of a standard static website running on Nginx. The symptoms were the same, links with a trailing slash (e.g. http://www.acme.com/products/) worked correctly, but omitting the trailing slash caused the user to be redirected to the origin.

    The issue is that the webserver software itself is not properly attempting to resolve URIs and is instead responding with a redirect to a URL it can serve. You can test this by using curl against your site:

    $ curl http://myhost.com/noslashurl
HTTP/1.1 301 Moved Permanently [...]

    CloudFront is returning exactly what your server returns, in this case a 301 redirect to your origin URL. Instead of following the redirect and caching that, CloudFront caches the redirect itself. The only way to correct this is to ensure that your origin properly handles the requests and does not respond with a 301.

    In my particular case, that meant updating the try_files directive for my location in the nginx configuration. As I mentioned this is a static site, and so my try_files became:

    location / {
    [...]
    try_files    $uri $uri/index.shtml /index.shtml =404;
}

    You want to be sure that the try_files has an endgame, to avoid redirection cycling which will cause your server to return 500 Server Errors when a non-existent URL is requested. In this case, /index.shtml is the last-ditch attempt and failing that, it will return a 404.

    I know this doesn’t precisely answer your question, but yours was one of a very few I found when searching for “cloudfront without trailing slash redirects to origin”, and you’ve not had an answer for a year, so I figured it was worth sending a response.

  2. I had the same problem.

    I fixed the issue changing some wordpress parameters.

    In the elasticbeanstalk I set the parameter CUSTOM_URL for my custom domain and in the file /var/www/html/wp-includes/load.php
    I set the parameters HTTP_HOST and SERVER_NAME to same value of CUSTOM_URL, and it resolved the redirect to elasticbeanstalk url.

    $_SERVER['HTTP_HOST'] = $_SERVER['CUSTOM_URL'];
$_SERVER['SERVER_NAME'] = $_SERVER['CUSTOM_URL'];