Indication des règles de réacheminement dans un fichier JSON

Jetons d'emplacement

Vous pouvez employer des jetons d'emplacement pour vous aider à créer l'emplacement de réacheminement. Tous les jetons d'emplacement suivants peuvent vous aider à indiquer un réacheminement :

• <$urlPath$> : partie de chemin de l'URL correspondante.

• <$urlQueryString$> : chaîne de requête d'URL complète de l'URL correspondante.

• <$urlQueryStringExcept(name1,name2)$> : chaîne de requête d'URL complète de l'URL correspondante moins les paramètres nommés.

• <$wildcard(N)$> : index de base 1 du caractère générique correspondant dans l'URL correspondante. (Analogue à \1..\9 dans les expressions régulières.)

• <$name$> : valeur du paramètre de chaîne de requête nommé. Par exemple, si vous avez la chaîne de requête msmith: ?page=42 sur l'entrée, vous pouvez utiliser <$page$> dans l'emplacement pour y indiquer '42'.

Restrictions

Les restrictions suivantes s'appliquent au fichier redirects.json dans son ensemble et aux règles qu'il contient :

• La taille de fichier globale maximale acceptée par Oracle Content Management est de 250 ko.

• Le nombre maximal de règles dans le fichier redirects.json est de 1 000.

• L'élément "expression" d'une règle ne doit pas dépasser 1 000 caractères.

• L'élément "location" d'une règle ne doit pas dépasser 2 000 caractères.

• Le nombre maximal de jetons '*' dans une expression de règle de caractère générique est de 10.

Exemple de correspondance de chaîne

Règle :

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

L'URL suivante correspondrait à la règle :

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

• L'emplacement obtenu serait : /new/material.htm

• L'URL complète correspond, y compris la chaîne de requête.

• Bien que <$id$> soit utilisé dans l'emplacement, il n'est pas nécessaire dans cet exemple, car une seule chaîne de requête peut correspondre. L'emplacement pourrait avoir été écrit comme suit : /new/material.htm.

Les URL suivantes ne correspondraient pas à la règle :

• /old/page.jsp

  (L'expression de la règle donne une chaîne de requête qui doit correspondre.)

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

  (L'élément supplémentaire &index=2 dans l'URL candidate ne correspond pas exactement à l'expression de règle.)

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

  (L'ordre des paramètres de chaîne de requête doivent correspondre dans une règle de chaîne.)

Exemple de correspondance de caractères génériques

Règle :

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

Les URL suivantes correspondraient à la règle :

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

  • L'emplacement obtenu serait : /new/XT1045/specs.html

  • La partie de chemin de l'URL correspond, les conditions de correspondance de la chaîne de requête sont donc également examinées.

  • Dans cet exemple, les paramètres correspondent à l'ordre des paramètres dans l'expression de règle, mais ce n'est pas obligatoire.

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

  • L'emplacement obtenu serait : /new/XT1045/specs.html

  • La partie de chemin de l'URL avant le point d'interrogation (?) correspond à l'expression de règle, la correspondance des paramètres est donc également vérifiée.

  • Même si les paramètres sont répertoriés dans un ordre différent dans l'expression de règle, ils correspondent individuellement.

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

  • L'emplacement obtenu serait : /new/XT1045/specs.html

  • La partie de chemin de l'URL correspond, les conditions de correspondance de la chaîne de requête sont donc également examinées.

  • L'URL candidate possède un paramètre &unrelated=thing supplémentaire, mais comme les paramètres de requête nommés dans l'expression de règle correspondent, la règle est considérée comme correspondante.

  • Le paramètre unrelated serait disponible dans l'emplacement en tant que jeton <$unrelated$> et aurait la valeur thing, même s'il ne contribue pas à la correspondance de la règle.

Les URL suivantes ne correspondraient pas :

• /old/pages/info.jsp

  (La partie de chemin de l'URL ne correspond pas à la partie de chemin de l'expression de règle.)

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

  (La partie de chemin de l'URL correspond à la partie de chemin de l'expression de règle, mais les paramètres de requête dans l'expression de règle ne correspondent pas.)

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

  (La partie de chemin de l'URL correspond à la partie de chemin de l'expression de règle, mais certains paramètres de requête dans l'expression de règle ne correspondent pas.)

Définition d'un tableau de jetons

Vous pouvez également créer un tableau de définitions de jeton dans le fichier redirects.json afin de faciliter la configuration des réacheminements prenant en charge plusieurs URL de produit. Vous pouvez ainsi effectuer un réacheminement correct en fonction des caractéristiques de l'URL entrante.

Employez le format suivant dans le fichier redirects.json pour définir les jetons à utiliser dans les URL de règles de réacheminement.

{
         "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"
                },              
        ]
}

Le tableau tokenDefinitions possède les propriétés suivantes :

• "token" : nom du jeton à définir.

• "type" : une des options suivantes :

  • "hostmatch" : permet de mettre en correspondance la valeur d'hôte de l'URL entrante.

  • "pathmatch" : permet de mettre en correspondance la valeur de chemin d'accès de l'URL entrante.

  • "querymatch" : permet de mettre en correspondance la valeur de requête de l'URL entrante.

• "expression" : expression à utiliser pour la correspondance. Les caractères génériques sont pris en charge.

• "value" : valeur à utiliser pour le jeton.

• "flags" : par défaut, la correspondance d'expression fait la distinction entre les majuscules et les minuscules sauf si la valeur flags est définie sur caseinsensitive

Lors du calcul de la valeur d'un jeton, le tableau tokenDefinitions est énuméré dans l'ordre. La première définition correspondante est utilisée. Si aucune définition de jeton ne correspond au jeton, une chaîne vide est utilisée à la place. A des fins de commodité et de performance, les jetons fréquemment utilisés doivent être placés au début de la liste tokenDefinitions.

Les contraintes suivantes s'appliquent au tableau tokenDefinitions :

• Vous pouvez créer jusqu'à 250 définitions de jeton.

• Le nom de token doit comporter moins de 100 caractères.

• expression peut contenir jusqu'à 10 caractères génériques.

• expression doit comporter moins de 1 000 caractères.

• value doit comporter moins de 1 000 caractères.

Exemple

Par exemple, le fichier redirects.json peut être le suivant :

{
         "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"
                },                                              
        ]
}

Dans ce cas, la propriété location contient un jeton <$pathPrefix$>. Le jeton pathPrefix est défini dans la section tokenDefinitions. Si l'URL entrante correspond à "vanity.com", la valeur pathPrefix sera définie sur /fashion. Cette valeur sera utilisée dans la réponse location, ce qui donnera : /fashion/about/new-privacy-policy.html.

Admettons que la première URL de domaine de produit est http://example.com/legacy-privacy-policy.html. L'URL correspond à la première et unique règle de réacheminement.

La propriété location déclarée pour cette règle est <$pathPrefix$>/about/new-privacy-policy.html. Dans ce cas, le jeton <$pathPrefix$> doit être évalué. Pour ce faire, le tableau tokenDefinitions est énuméré afin de trouver une correspondance.

La première définition de jeton est considérée. Puisque son jeton token est celui souhaité, son évaluation se poursuit. L'expression vanity.com ne correspond pas à l'élément example.com de l'URL entrante. Cette définition ne satisfait donc pas aux exigences et l'énumération continue.

A ce stade, il n'existe plus d'autre définition de jeton. Une chaîne vide est donc utilisée pour la valeur du jeton <$pathPrefix$>. L'emplacement final renvoyé pour ce réacheminement est /about/new-privacy-policy.html.

Admettons que la deuxième URL de domaine de produit est http://vanity.com/legacy-privacy-policy.html. Comme pour la première URL, la propriété location déclarée pour cette règle est <$pathPrefix$>/about/new-privacy-policy.html. Dans ce cas, le jeton <$pathPrefix$> doit être évalué. Pour ce faire, le tableau tokenDefinitions est énuméré afin de trouver une correspondance.

La première définition de jeton est considérée. Comme précédemment, puisque son jeton token est celui souhaité, son évaluation se poursuit. L'expression vanity.com correspond à l'élément vanity.com de l'URL entrante. Cette définition satisfait donc aux exigences et la valeur /fashion est utilisée en tant que valeur du jeton.

Une correspondance ayant été trouvée pour le jeton, l'énumération du tableau de définitions de jeton est arrêtée et l'emplacement final est calculé ainsi : /fashion/about/new-privacy-policy.html.

Test de réacheminements de site

Vous pouvez tester les réacheminements de site lors de la modification d'un site. Pour ce faire, ouvrez le panneau Paramètres et cliquez sur Réacheminements. Saisissez une URL à tester et cliquez sur Tester.