2013-04-23 62 views
2

我在重定向導致域更改WordPress重定向時遇到一些麻煩。Wordpress MU Cloudfront。跟蹤斜槓重定向到錯誤的域

例子: 網站 - noncdn.somedomain.com CDN URL - www.domain.com

當我打開鏈接瓦特/ OA斜線有301重定向: 去這裏:www.domain。轉到此處:noncdn.somedomain.com/page/

由於Cloudfront正在使用Origin Domain訪問服務器,服務器甚至不知道請求是從其他域進入的。

如何強制這301使用FQDN W/CDN正確域名,而不是做一個相對重定向?

我已經添加了這個讓網站和圖片的Cloudfront域的所有負載上的聯繫,但它似乎對重定向行爲沒有任何影響:

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; 
} 

任何幫助,非常感謝!

謝謝!

回答

1

我是跟蹤一個非常類似的問題,與上運行Nginx的一個標準的靜態網站的的Cloudfront分佈的一段時間。症狀是一樣的,鏈接以斜線(例如www.acme.com/products/)正常工作,但省略了斜槓導致用戶被重定向到原點。

的問題是,web服務器軟件本身沒有正確嘗試解析URI,並轉而使用重定向到URL它可以成爲響應。您可以通過使用curl對您的網站測試:

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

CloudFront的是返回正是你的服務器的回報,在這種情況下,301重定向你的源URL。 CloudFront並不是遵循重定向和緩存,而是緩存重定向本身。糾正這種情況的唯一方法是確保您的原點正確處理請求,並且不迴應301.

在我的特殊情況下,這意味着要更新我在nginx配置中的位置的try_files directive。正如我所說,這是一個靜態的網站,所以我try_files變成了:

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

你想成爲確保try_files具有殘局,避免重定向循環,這將導致服務器返回500服務器錯誤時請求不存在的URL。在這種情況下,/index.shtml是最後一次嘗試和失敗,它將返回一個404.

我知道這並不能準確地回答你的問題,但你是我發現時的少數幾個搜索「沒有將斜線重定向到原點的雲端」,並且你一年沒有答案,所以我認爲值得發送回覆。

0

我有同樣的問題。

我固定改變某些參數的WordPress的問題。

在elasticbeanstalk我設置的參數CUSTOM_URL爲我的自定義域和文件/var/www/html/wp-includes/load.php 在我設定的參數HTTP_HOSTSERVER_NAMECUSTOM_URL相同的價值,它解決了重定向到URL elasticbeanstalk。

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

似乎不是理想的編輯WordPress核心文件,如load.php,可能會覆蓋未來的更新。有任何其他方式來實現這樣的事情? – Jordan 2016-08-18 01:28:31