Especificar Regras de Redirecionamentos em um Arquivo JSON

Tokens de Local

Você pode usar tokens de local para ajudar na criação de um local de redirecionamento. Cada um dos seguintes tokens de local pode ajudar a especificar um redirecionamento:

• <$urlPath$>: a parte do caminho do URL de correspondência.

• <$urlQueryString$>: a string de consulta do URL inteiro com base no URL de correspondência.

• <$urlQueryStringExcept(name1,name2)$>: a string de consulta do URL inteiro com base no URL de correspondência, menos os parâmetros nomeados.

• <$wildcard(N)$>: o índice baseado em um do curinga de correspondência no URL de correspondência. (Isso é análogo ao \1..\9 nas expressões regulares.)

• <$name$>: o valor do parâmetro nomeado da string de consulta. Por exemplo, se você tiver a string de consulta msmith: ?page=42 na entrada, poderá usar <$page$> no local para colocar '42' no local.

Restrições

As seguintes restrições se aplicam ao arquivo redirects.json como um todo e às regras que ele contém:

• O tamanho do arquivo geral máximo aceito pelo Oracle Content Management é 250 KB.

• O número máximo de regras no arquivo redirects.json é 1.000.

• O tamanho máximo da "expressão" de uma regra é 1.000 caracteres.

• O tamanho máximo do "local" de uma regra é 2.000 caracteres.

• O número máximo de tokens '*' em uma expressão de regra curinga é 10.

Exemplo de Correspondência de String

Regra:

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

O seguinte URL corresponderia à regra:

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

• O local resultante seria: /new/material.htm

• O URL inteiro corresponde, inclusive a string de consulta.

• Embora <$id$> seja usado no local, não é necessário neste exemplo porque apenas uma string de consulta possível poderia corresponder. O local deve ter sido gravado como /new/material.htm.

Os seguintes URLs não corresponderiam à regra:

• /old/page.jsp

  (A expressão da regra fornece uma string de consulta que deve corresponder.)

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

  (O &index=2 extra no URL candidato não é uma correspondência exata da expressão da regra.)

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

  (A ordem dos parâmetros da string de consulta deve corresponder em uma regra de “string”.)

Exemplo de Correspondência Curinga

Regra:

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

Os seguintes URLs corresponderiam à regra:

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

  • O local resultante seria: /new/XT1045/specs.html

  • A parte do caminho do URL corresponde, de modo que a string de consulta também é examinada em busca de condições de correspondência.

  • Os parâmetros neste exemplo acontecem para corresponder a ordem dos parâmetros na expressão da regra, mas isso não é obrigatório.

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

  • O local resultante seria: /new/XT1045/specs.html

  • A parte do caminho do URL corresponde à expressão da regra antes do ponto de interrogação (?); assim, os parâmetros também são verificados para obter uma correspondência.

  • Embora os parâmetros sejam listados em uma ordem diferente na expressão da regra, eles são correspondidos individualmente.

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

  • O local resultante seria: /new/XT1045/specs.html

  • A parte do caminho do URL corresponde, de modo que a string de consulta também é examinada em busca de condições de correspondência.

  • O URL candidato tem um parâmetro &unrelated=thing extra, mas como os parâmetros nomeados de consulta na expressão da regra correspondem, a regra é considerada para correspondência.

  • O parâmetro unrelated estaria disponível no local como token, como <$unrelated$>, e teria o valor thing, mesmo não tendo contribuído para a correspondência da regra.

Os seguintes URLs não corresponderiam:

• /old/pages/info.jsp

  (A parte do caminho do URL não corresponde à parte do caminho da expressão da regra.)

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

  (A parte do caminho do URL corresponde à parte do caminho da expressão da regra, mas os parâmetros da consulta na expressão da regra não correspondem.)

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

  (A parte do caminho do URL corresponde à parte do caminho da expressão da regra, mas nem todos os parâmetros da consulta na expressão da regra correspondem.)

Definindo um Array de Token

Você também pode criar um array de definições de token no arquivo redirects.json para ajudar a configurar redirecionamentos que suportam diversos URLs personalizados. Isso permite redirecionar apropriadamente com base nas características do URL de entrada.

Use o formato a seguir no arquivo redirects.json para definir os tokens para uso em URLs de regras de redirecionamento.

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

O tokenDefinitions tem as seguintes propriedades:

• "token": O nome do token a ser definido.

• "type": Um dos seguintes:

  • "hostmatch" para corresponder ao valor do host do URL de entrada.

  • "pathmatch" para corresponder ao valor do nome do caminho do URL de entrada.

  • "querymatch" para corresponder ao valor da consulta do URL de entrada.

• "expression": A expressão que deve ser usada para correspondência. Caracteres curinga são suportados.

• "value": O valor que deve ser usado para correspondência.

• "flags": Por padrão, a correspondência de expressão distinguirá maiúsculas de minúsculas, a menos que o valor flags seja definido como caseinsensitive

Ao calcular o valor de um token, o array tokenDefinitions será enumerado na ordem. A primeira definição de correspondência será usada. Se nenhuma definição satisfizer o token, uma string vazia será usada em seu lugar. Por conveniência e desempenho, os tokens comumente usados devem ser colocados no início da lista tokenDefinitions.

O array tokenDefinitions tem as seguintes restrições:

• Você pode criar até 250 definições de token.

• O nome do token deve ter menos de 100 caracteres.

• O expression pode ter até 10 caracteres curinga.

• O expression deve ter menos de 1000 caracteres.

• O value deve ter menos de 1000 caracteres.

Exemplo

Por exemplo, você pode ter o seguinte arquivo 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"
                },                                              
        ]
}

Nesse caso, a propriedade location da regra tem um token <$pathPrefix$>. O token pathPrefix é definido na seção tokenDefinitions. Se o URL de entrada corresponder a "vanity.com", o valor pathPrefix será definido como /fashion. Isso será usado na resposta location, resultando em /fashion/about/new-privacy-policy.html.

Vamos supor que o primeiro URL de domínio personalizado seja http://example.com/legacy-privacy-policy.html. Isso corresponderia à primeira e única regra de redirecionamento.

O valor location declarado para essa regra é <$pathPrefix$>/about/new-privacy-policy.html. Nesse caso, o token <$pathPrefix$> precisa ser avaliado. Para isso, o array tokenDefinitions é enumerado para encontrar uma correspondência.

A primeira definição de token é considerada. Seu token é declarado como um, sendo assim avaliado ainda mais. A expressão vanity.com não corresponde ao example.com do URL de entrada, ou seja, essa definição não satisfaz aos requisitos e a enumeração continua.

Nesse ponto, não há mais definições de token, de modo que a string vazia é usada para o valor do token <$pathPrefix$>. O local final retornado para esse redirecionamento é /about/new-privacy-policy.html.

Vamos supor que o segundo URL de domínio personalizado seja http://vanity.com/legacy-privacy-policy.html. Como com o primeiro URL, o valor location declarado para essa regra é <$pathPrefix$>/about/new-privacy-policy.html. Nesse caso, o token <$pathPrefix$> precisa ser avaliado. Para isso, o array tokenDefinitions é enumerado para encontrar uma correspondência.

A primeira definição de token é considerada. Como antes, seu token é declarado como um, sendo assim avaliado ainda mais. A expressão vanity.com corresponde ao vanity.com do URL de entrada, ou seja, essa definição satisfaz aos requisitos e o valor /fashion é usado como valor do token.

Como uma correspondência para o token foi encontrada, a enumeração do array de definições de token é interrompida e o local final é calculado como /fashion/about/new-privacy-policy.html.

Testando os Redirecionamentos do Site

Você pode testar os redirecionamentos do site ao editar um site abrindo o painel Definições e clicando em Redirecionamentos. Digite um URL a ser testado e clique em Testar.