Specificare le regole di reindirizzamento in un file JSON

È possibile specificare le regole di reindirizzamento per gli URL in un file JSON.

Per specificare le regole di reindirizzamento per gli URL, utilizzare il formato riportato di seguito in un file 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
                }
        ]
}

La struttura contenitore esterna nel file di JSON è un array. L'array contiene le istanze delle regole.

Le regole "string" verranno valutate per prime, seguite nell'ordine dalle regole "wildcard". Quando una delle regole corrisponde, la valutazione delle regole successive viene abbandonata e viene generato il reindirizzamento corrispondente.

Ogni regola dispone delle proprietà riportate di seguito.

  • La proprietà "comment" è una stringa facoltativa che non ha alcun impatto sulla valutazione delle regole. Include note o commenti.

  • La proprietà "expression" è una stringa obbligatoria che viene confrontata con l'URL relativo del sito in entrata. In una regola di tipo wildcard, il token asterisco (*) corrisponde a zero o più caratteri.

  • La proprietà "location" è una stringa obbligatoria che indica la posizione o la destinazione del reindirizzamento. Il reindirizzamento può essere un URL completo o relativo.

  • La proprietà "code" è un numero intero facoltativo che fornisce il codice di risposta HTTP da utilizzare quando si esegue il reindirizzamento. Il valore deve essere uno dei numeri interi riportati di seguito.

    • 301: indica che la risorsa è stata spostata definitivamente. Si tratta del valore predefinito utilizzato quando la proprietà "code" viene omessa.

    • 302: indica che la risorsa è stata spostata temporaneamente.

  • La proprietà "type" è una stringa facoltativa che indica il tipo della regola di reindirizzamento. Il valore deve essere una delle stringhe descritte di seguito.

    • "string" specifica una regola più veloce la cui espressione corrisponde esattamente all'intero URL di input.

    • "wildcard" specifica una regola wildcard che può corrispondere a vari URL. Si tratta del valore predefinito utilizzato quando la proprietà viene omessa.

Token di posizione

I token di posizione facilitano la definizione della posizione di reindirizzamento. Ognuno dei token di posizione seguenti può contribuire a specificare meglio un reindirizzamento.

  • <$urlPath$>: la parte percorso dell'URL corrispondente.

  • <$urlQueryString$>: l'intera stringa di query URL dell'URL corrispondente.

  • <$urlQueryStringExcept(name1,name2)$>: l'intera stringa di query URL dell'URL corrispondente senza i parametri specificati.

  • <$wildcard(N)$>: l'indice con base uno del carattere jolly corrispondente nell'URL corrispondente. (È analogo a \1..\9 nelle espressioni regolari).

  • <$name$>: il valore del parametro della stringa di query specificato. Ad esempio, se si dispone della stringa di query msmith: ?page=42 nell'input, è possibile utilizzare <$page$> nella posizione per inserirvi '42'.

Limitazioni

Le limitazioni riportate di seguito vengono applicate all'intero file redirects.json e alle regole che contiene.

  • La dimensione file globale massima accettata da Oracle Content Management è pari a 250 KB.

  • Il numero massimo delle regole nel file redirects.json è fissato a 1.000.

  • La lunghezza massima di una stringa "expression" per una regola è di 1.000 caratteri.

  • La lunghezza massima di una stringa "location" per una regola è di 2.000 caratteri.

  • Il numero massimo di token '*' in un'espressione della regola di tipo wildcard è 10.

Esempio di corrispondenza di una regola string

Regola:

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

L'URL seguente corrisponderebbe alla regola:

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

  • La posizione risultante sarebbe /new/material.htm

  • L'intero URL, compresa la stringa di query, corrisponde.

  • Sebbene venga utilizzato nella posizione, <$id$> non è necessario per questo esempio perché potrebbe corrispondere una sola stringa di query possibile. La posizione avrebbe potuto essere specificata con /new/material.htm.

Gli URL riportati di seguito non corrisponderebbero alla regola.

  • /old/page.jsp

    (L'espressione della regola specifica una stringa di query che deve corrispondere).

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

    (L'elemento extra &index=2 nell'URL candidato non corrisponde esattamente all'espressione della regola).

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

    (L'ordine dei parametri della stringa di query deve corrispondere in una regola di tipo "string").

Esempio di corrispondenza di una regola wildcard

Regola:

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

Gli URL riportati di seguito corrisponderebbero alla regola.

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

    • La posizione risultante sarebbe /new/XT1045/specs.html.

    • La parte percorso dell'URL corrisponde, pertanto la stringa di query viene esaminata anche per le condizioni corrispondenti.

    • I parametri in questo esempio corrispondono all'ordine dei parametri nell'espressione della regola, ma tale corrispondenza non è obbligatoria.

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

    • La posizione risultante sarebbe /new/XT1045/specs.html.

    • La parte percorso dell'URL corrisponde all'espressione della regola prima del punto interrogativo (?), pertanto la corrispondenza viene verificata anche per i parametri.

    • Anche se sono elencati in un ordine differente nell'espressione della regola, i parametri vengono confrontati singolarmente.

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

    • La posizione risultante sarebbe /new/XT1045/specs.html.

    • La parte percorso dell'URL corrisponde, pertanto la stringa di query viene esaminata anche per le condizioni corrispondenti.

    • L'URL candidato contiene un parametro &unrelated=thing extra, ma poiché i parametri di query specificati nell'espressione della regola corrispondono, la regola viene considerata corrispondente.

    • Il parametro unrelated sarebbe disponibile nella posizione come token <$unrelated$> e avrebbe il valore thing, anche se non è stato preso in considerazione per la corrispondenza della regola.

Gli URL riportati di seguito non corrisponderebbero.

  • /old/pages/info.jsp

    (La parte percorso dell'URL non corrisponde alla parte percorso dell'espressione della regola).

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

    (La parte percorso dell'URL corrisponde alla parte percorso dell'espressione della regola, ma i parametri della query nell'espressione della regola non corrispondono).

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

    (La parte percorso dell'URL corrisponde alla parte percorso dell'espressione della regola, ma non tutti i parametri della query nell'espressione della regola corrispondono).

Definizione di un array di token

È inoltre possibile creare un array di definizioni di token all'interno del file redirects.json in modo da facilitare la configurazione dei reindirizzamenti che supportano più URL univoci. Ciò consente di effettuare il reindirizzamento in modo appropriato in base alle caratteristiche dell'URL in entrata.

Per definire i token da usare negli URL delle regole di reindirizzamento, usare il formato riportato di seguito nel file redirects.json.

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

L'array tokenDefinitions dispone delle proprietà riportate di seguito.

  • "token": nome del token da definire.

  • "type": uno dei seguenti:

    • "hostmatch" per corrispondere al valore dell'host dell'URL in entrata.

    • "pathmatch" per corrispondere al valore del nome percorso dell'URL in entrata.

    • "querymatch" per corrispondere al valore della query dell'URL in entrata.

  • "expression": espressione da usare per la corrispondenza. I caratteri jolly sono supportati.

  • "value": valore da usare per il token.

  • "flags": per impostazione predefinita, la corrispondenza dell'espressione fa distinzione tra maiuscole e minuscole a meno che il valore di flags non sia impostato su caseinsensitive

Durante il calcolo del valore di un token, l'array tokenDefinitions viene esaminato nell'ordine di enumerazione. Verrà utilizzata la prima definizione corrispondente. Se nessuna definizione di token soddisfa il token, verrà utilizzata una stringa vuota. Per convenienza e migliori prestazioni, i token comunemente utilizzati dovrebbe essere posizionati in cima alla lista di tokenDefinitions.

L'array tokenDefinitions presenta i vincoli riportati di seguito.

  • È possibile creare fino a 250 definizioni di token.

  • Il nome del token deve contenere meno di 100 caratteri.

  • expression può contenere fino a 10 caratteri jolly.

  • expression deve contenere meno di 1000 caratteri.

  • value deve contenere meno di 1000 caratteri.

Esempio

Ad esempio, si potrebbe disporre del file redirects.json riportato di seguito.

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

In questo caso, la proprietà location della regola ha un token <$pathPrefix$>. Il token pathPrefix è definito nella sezione tokenDefinitions. Se l'URL in entrata corrisponde a "vanity.com", il valore pathPrefix verrà impostato su /fashion. Questo valore verrà usato nella risposta location, risultando in /fashion/about/new-privacy-policy.html.

Si supponga che il primo URL di dominio univoco sia http://example.com/legacy-privacy-policy.html. Questo corrisponderebbe alla prima e unica regola di reindirizzamento.

Il valore location dichiarato per questa regola è <$pathPrefix$>/about/new-privacy-policy.html. In questa situazione, è necessario calcolare il token <$pathPrefix$>. A tal fine, le definizioni nell'array tokenDefinitions vengono esaminate nell'ordine di enumerazione per trovare una corrispondenza.

Viene considerata la prima definizione di token. Il relativo valore token è quello desiderato, quindi verrà effettuata una ulteriore valutazione. L'espressione vanity.com non corrisponde a example.com dell'URL in entrata pertanto questa definizione non soddisfa i requisiti e si continuerà esaminando le altre definizioni.

A questo punto, non essendoci altre definizioni di token, per il valore del token <$pathPrefix$> verrà usata la stringa vuota. La posizione finale restituita per questo reindirizzamento è /about/new-privacy-policy.html.

Si supponga che il secondo URL di dominio univoco sia http://vanity.com/legacy-privacy-policy.html. Come per il primo URL, il valore location dichiarato per questa regola è <$pathPrefix$>/about/new-privacy-policy.html. In questa situazione, è necessario calcolare il token <$pathPrefix$>. A tal fine, le definizioni nell'array tokenDefinitions vengono esaminate nell'ordine di enumerazione per trovare una corrispondenza.

Viene considerata la prima definizione di token. Come in precedenza, il relativo valore token è quello desiderato, quindi verrà effettuata una ulteriore valutazione. L'espressione vanity.com corrisponde a vanity.com dell'URL in entrata pertanto questa definizione soddisfa i requisiti e il valore /fashion viene usato come valore del token.

Poiché una corrispondenza per il token è stata trovata, l'esame dell'array delle definizioni di token viene arrestato e la posizione finale calcolata è /fashion/about/new-privacy-policy.html.

Test dei reindirizzamenti del sito

Per eseguire il test dei reindirizzamenti del sito quando si modifica un sito, è possibile aprire il pannello Impostazioni e fare clic su Reindirizzamenti. Immettere un URL da sottoporre a test e fare clic su Test.

Pannello di test dei reindirizzamenti