JSONファイル内のリダイレクト・ルールの指定

JSONファイル内のURLのリダイレクト・ルールを指定できます。

URLのリダイレクト・ルールを指定するには、JSONファイルで次のフォーマットを使用します。

{
         "redirectRules":
         [
                {
                        "type": "string",
                        "comment": "this rule is applied first",
                        "expression": "/index.htm",
                        "location": "/home.html"
                },
                {
                        "type": "wildcard",
                        "expression": "/items/*?page=*",
                        "location": "/<$page$>?item=<$wildcard(1)$>",
                        "code": 302
                }
        ]
}

JSONファイルの外部格納構造は配列です。配列にはルール・インスタンスが含まれています。

"string"ルールが最初に評価され、続いて"wildcard"ルールが順番に評価されます。ルールの1つが一致すると、後続のルールの評価は放棄され、対応するリダイレクトが生成されます。

各ルールには次のプロパティがあります:

  • The "comment"プロパティは、ルールの評価に影響を与えないオプションのストリングです。注釈や解説が含まれています。

  • "expression"プロパティは、受信サイトの相対URLと一致する必須文字列です。ワイルドカード・ルールでは、アスタリスク(*)トークンは0個以上の文字と一致します。

  • "location"プロパティは、リダイレクトの場所または宛先を示す必須文字列です。リダイレクトには、完全URLまたは相対URLを使用できます。

  • "code"プロパティは、リダイレクトを発行するときに使用するHTTPレスポンス・コードを提供するオプションの整数です。値は次の整数のいずれかである必要があります:

    • 301: リソースが永久に移動したことを示します。これは、"code"プロパティが省略された場合のデフォルト値です。

    • 302: リソースが一時的に移動したことを示します。

  • "type"プロパティは、リダイレクト・ルールのタイプを示すオプションの文字列です。値は次のいずれかの文字列である必要があります:

    • "string"は、式が入力URL全体と正確に一致する、より高速なルールを指定します。

    • "wildcard"は、複数のURLに一致するワイルドカード・ルールを指定します。プロパティが省略されている場合、これがデフォルト値です。

場所トークン

場所トークンを使用して、リダイレクト場所の作成を支援できます。次の各場所トークンは、リダイレクトの指定に役立ちます:

  • <$urlPath$>: 一致するURLのパス部分。

  • <$urlQueryString$>: 一致するURLのURL問合せ文字列全体。

  • <$urlQueryStringExcept(name1,name2)$>: 一致するURLからのURL問合せ文字列全体から、指定されたパラメータを引いたものです。

  • <$wildcard(N)$>: 一致するURLの一致するワイルドカードの1から始まる索引。(これは正規表現の\1..\9に似ています。)

  • <$name$>: 名前付き問合せ文字列パラメータの値。たとえば、入力に問合せ文字列msmith: ?page=42がある場合、<$page$>を使用してその場所に'42'を配置できます。

制限

redirects.jsonファイル全体およびそれに含まれるルールには、次の制限が適用されます:

  • Oracle Content Managementで受け入れられるファイル全体の最大サイズは250KBです。

  • redirects.jsonファイル内のルールの最大数は1,000です。

  • ルールの"expression"の最大長は1,000文字です。

  • ルールの"location"の最大長は2,000文字です。

  • ワイルドカード・ルール式の'*'トークンの最大数は10です。

文字列一致の例

ルール:

        {
              "type": "string",
              "expression": "/old/page.jsp?id=material&type=glass",
              "location": "/new/<$id$>.htm"
        }

次のURLはルールに一致します:

/old/page.jsp?id=material&type=glass

  • 結果の場所: /new/material.htm

  • 問合せ文字列を含むURL全体が一致します。

  • <$id$>がその場所で使用されていますが、使用可能な問合せ文字列が1つしか一致できないため、この例では必要ありません。場所は/new/material.htmと書かれていた可能性があります。

次のURLはルールに一致しません:

  • /old/page.jsp

    (ルールの式は、一致する必要がある問合せ文字列を与えます。)

  • /old/page.jsp?id=material&type=glass&index=2

    (候補URL内の余分な&index=2がルール式と正確に一致しません。)

  • /old/page.jsp?type=glass&id=material

    (問合せ文字列パラメータの順序は、「文字列」ルールで一致する必要があります。)

ワイルドカード一致の例:

ルール:

        {
              "type": "wildcard",
              "expression": "/old/*/pages/*?id=*&item=sheet-*",
              "location": "/new/<$id$>/<$wildcard(4)$>.html"
        }

次のURLはルールに一致します:

  • /old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs

    • 結果の場所: /new/XT1045/specs.html

    • URLのパス部分が一致するので、問合せ文字列も一致条件について調査されます。

    • この例のパラメータは、ルール式のパラメータの順序と一致しますが、これは必須ではありません。

  • /old/phones/android/pages/info.asp?item=sheet-specs&id=XT1045

    • 結果の場所: /new/XT1045/specs.html

    • URLのパス部分は疑問符(?)の前のルール式と一致するため、パラメータも一致するかチェックされます。

    • パラメータはルール式内で異なる順序でリストされますが、パラメータは個別に一致します。

  • /old/phones/android/pages/info.asp?id=XT1045&item=sheet-specs&unrelated=thing

    • 結果の場所: /new/XT1045/specs.html

    • URLのパス部分が一致するので、問合せ文字列も一致条件について調査されます。

    • 候補URLには追加の&unrelated=thingパラメータがありますが、ルール式の名前付き問合せパラメータが一致するため、ルールは一致すると見なされます。

    • unrelatedパラメータは、<$unrelated$>のように場所内でトークンとして使用でき、ルールの一致には寄与しなかったとしても、thingという値を持ちます。

次のURLは一致しません:

  • /old/pages/info.jsp

    (URLのパス部分がルール式のパス部分と一致しません。)

  • /old/phones/android/pages/info.asp

    (URLのパス部分はルール式のパス部分と一致しますが、ルール式の問合せパラメータは一致しません。)

  • /old/phones/android/pages/info.asp?id=cellular

    (URLのパス部分はルール式のパス部分と一致しますが、ルール式のすべての問合せパラメータが一致するわけではありません。)

トークン配列の定義

redirects.jsonファイル内のトークン定義の配列を作成して、複数のバニティURLをサポートするリダイレクトを構成する際に役立てることもできます。これにより、受信URLの特性に基づいて適切にリダイレクトできます。

redirects.jsonファイル内で次の形式を使用してリダイレクト・ルールURLで使用するトークンを定義します。

{
         "tokenDefinitions":
         [
                {
                        "token": "sitePrefix",
                        "type": "hostmatch",
                        "expresion": "example.com"
                        "value": ""
                },
                {
                        "token": "sitePrefix",
                        "type": "hostmatch",
                        "expresion": "*.com"
                        "value": "/site/Starter-Site"
                },
                {
                        "token": "gotoRedirect",
                        "type": "pathmatch",
                        "expresion": "*oracle*"
                        "value": "https://www.oracle.com"
                        "flags": "caseinsensitive"
                },              
        ]
}

tokenDefinitionsには次のプロパティがあります。

  • "token": 定義するトークンの名前。

  • "type": 次のいずれか。

    • 受信URLのホスト値を照合する"hostmatch"。

    • 受信URLのパス名値を照合する"pathmatch"。

    • 受信URLの問合せ値を照合する"querymatch"。

  • "expression": 照合に使用する必要のある式。ワイルドカード文字がサポートされます。

  • "value": トークンに使用する必要のある値。

  • "flags": デフォルトでは、flags値がcaseinsensitiveに設定されていないかぎり、式の照合では大文字と小文字が区別されます

トークンの値を計算する場合、tokenDefinitions配列が順番に列挙されます。最初に一致する定義が使用されます。トークンを満たすトークン定義がない場合は、かわりに空の文字列が使用されます。便宜とパフォーマンスのために、よく使用されるトークンはtokenDefinitionsリストの先頭に配置する必要があります。

tokenDefinitionsには次の制約があります。

  • 作成できるトークン定義は250個までです。

  • token名は100文字未満にする必要があります。

  • expressionで使用できるワイルドカードは10個までです。

  • expressionは1000文字未満にする必要があります。

  • valueは1000文字未満にする必要があります。

例

たとえば、次のredirects.jsonファイルがあるとします。

{
         "redirectRules":
         [
                {
                        "type": "string",
                        "expression": "/legacy-privacy-policy.html",
                        "location": "<$pathPrefix$>/about/new-privacy-policy.html"
                },              
        ]
         "tokenDefinitions":
         [
                {
                        "token": "pathPrefix",
                        "type": "hostmatch",
                        "expression": "vanity.com"
                        "value": "/fashion"
                },                                              
        ]
}

この場合、locationプロパティには<$pathPrefix$>トークンがあります。pathPrefixトークンはtokenDefinitionsセクションで定義されます。受信URLが"vanity.com"と一致する場合、pathPrefix値は/fashionに設定されます。これはlocationレスポンスで使用され、/fashion/about/new-privacy-policy.htmlになります。

最初のバニティ・ドメインURLがhttp://example.com/legacy-privacy-policy.htmlであると仮定しましょう。これは最初のリダイレクト・ルールとのみ一致します。

このルールに対して宣言されたlocationは<$pathPrefix$>/about/new-privacy-policy.htmlです。この状況では、<$pathPrefix$>トークンを評価する必要があります。そのために、tokenDefinitions配列が列挙されて一致が検索されます。

最初のトークン定義が検討されます。そのtokenは目的のものであるため、さらに評価されます。式vanity.comは受信URLのexample.comと一致しないため、この定義は要件を満たさず、列挙が続行されます。

この時点で、これ以上トークン定義はないため、<$pathPrefix$>トークンの値には空の文字列が使用されます。このリダイレクトに対して返される最終的な場所は/about/new-privacy-policy.htmlです。

2番目のバニティ・ドメインURLがhttp://vanity.com/legacy-privacy-policy.htmlであると仮定しましょう。最初のURLの場合と同様に、このルールに対して宣言されたlocationは<$pathPrefix$>/about/new-privacy-policy.htmlです。この状況では、<$pathPrefix$>トークンを評価する必要があります。そのために、tokenDefinitions配列が列挙されて一致が検索されます。

最初のトークン定義が検討されます。前と同様に、そのtokenは目的のものであるため、さらに評価されます。式vanity.comは受信URLのvanity.comと一致するため、この定義は要件を満たし、値/fashionがトークンの値として使用されます。

トークンとの一致が見つからなかったため、トークン定義配列の列挙が停止し、最終的な場所は/fashion/about/new-privacy-policy.htmlとして計算されます。

サイト・リダイレクトのテスト

「設定」パネルを開き、「リダイレクト」をクリックすることにより、サイトを編集するときにサイト・リダイレクトをテストできます。テストするURLを入力し、「テスト」をクリックします。

リダイレクトのテスト・パネル