URL重新導向

URL重新導向是網站作業中常見的方面。 架構師和管理員必須尋找最佳解決方案，瞭解如何及到哪裡管理URL重新導向，以提供彈性及快速的重新導向部署時間。

請務必熟悉AEM (6.x) aka AEM Classic和AEM as a Cloud Service基礎結構。 主要差異為：

其他AEM服務(AEM Author/Publish和Dispatcher)在AEM 6.x和AEM as a Cloud Service之間的概念類似。

AEM的URL重新導向解決方案如下：

解決方案選項

以下是解決方案選項，依離網站訪客瀏覽器較近的順序排列。

在Edge，透過AEM管理的CDN at-edge-via-aem-managed-cdn

此選項僅適用於AEM as a Cloud Service客戶。

AEM管理的CDN提供Edge層級的重新導向解決方案，因此可減少到來源的來回次數。 使用者端重新導向功能可讓您在AEM專案程式碼中設定重新導向規則，並使用設定管道進行部署。 CDN設定檔(cdn.yaml)大小不應超過100KB。

在Edge或CDN層級管理重新導向具有效能優勢。

在Edge，透過自備CDN

有些CDN服務提供了Edge層級的重新導向解決方案，因此減少了前往原點的往返次數。 請參閱Akamai Edge重新導向程式、AWS CloudFront函式。 請洽詢您的CDN服務提供者，以瞭解Edge層級重新導向功能。

在Edge或CDN層級管理重新導向具有效能優勢，不過這些並不會作為AEM的一部分進行管理，而是作為獨立專案的一部分進行管理。 定義良好的流程來管理和部署重新導向規則對避免問題至關重要。

Apache mod_rewrite模組

通用解決方案使用Apache模組mod_rewrite。 AEM專案原型提供AEM 6.x和AEM as a Cloud Service專案的Dispatcher專案結構。 預設（不可變）和自訂重寫規則定義於conf.d/rewrites資料夾中，且透過conf.d/dispatcher_vhost.conf檔案在連線埠80上接聽的virtualhosts的重寫引擎已開啟。 AEM WKND Sites專案中提供範例實作。

在AEM as a Cloud Service中，這些重新導向規則是作為AEM程式碼的一部分來管理，並透過Cloud Manager 網頁層設定管道或完整棧疊管道來部署。 因此，您的AEM專案特定程式將用於管理、部署和追蹤重新導向規則。

大部分的CDN服務都會根據其Cache-Control或Expires標頭快取HTTP 301和302重新導向。 它有助於避免在Apache/Dispatcher中起始的初始重新導向後出現來回次數。

ACS AEM Commons

ACS AEM Commons中有兩項功能可用來管理URL重新導向。 請注意，ACS AEM Commons是社群運作的開放原始碼專案，Adobe不支援。

重新導向地圖管理員

重新導向地圖管理員可協助AEM 6.x系統管理員輕鬆維護和發佈Apache RewriteMap檔案，而不需要直接存取Apache Web伺服器或重新啟動Apache Web伺服器。 此功能可讓許可權使用者從AEM中的主控台建立、更新和刪除重新導向規則，無需開發團隊或AEM部署的協助。 重新導向地圖管理員​ 與AEM as a Cloud Service不相容。

重新導向管理員

重新導向管理員可讓AEM中的使用者輕鬆地維護和發佈AEM的重新導向。 實作是以Java™ servlet篩選器為基礎，因此是典型的JVM資源消耗。 此功能也會消除對AEM開發團隊和AEM部署的相依性。 重新導向管理員與​ AEM as a Cloud Service ​和​ AEM 6.x ​相容。 雖然初始的重新導向請求必須命中AEM Publish服務，以依預設產生301/302 （大多數） CDN的快取301/302，並允許後續請求被重新導向到edge/CDN。

Redirect頁面屬性

來自進階索引標籤的現成(OOTB) Redirect頁面屬性可讓內容作者定義目前頁面的重新導向位置。 此解決方案最適合每個頁面重新導向案例，且沒有可檢視及管理頁面重新導向的中央位置。

哪個解決方案適合實施

以下是一些判斷正確解決方案的條件。 此外，貴組織的IT和行銷流程應該有助於挑選正確的解決方案。