Risoluzione degli errori di deployment del criterio di Protezione espressioni regolari

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza Documentazione di Apigee Edge.

InvalidRegularExpression

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

Messaggio di errore di esempio

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

Screenshot di esempio di errore

Testo dell'errore InvalidRegularExpression

Causa

Se l'espressione regolare nell'elemento <Pattern> del criterio RegularExpressionProtection non è valida, il deployment dell'API Proxy non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection dal messaggio di errore. Ad esempio, nell'errore seguente, il nome del criterio RegularExpressionProtection è Regular-Expression-Protection-1:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Invalid Regular Expression com.apigee.steps.regexprotection.RegularExpressionProtectionBean$RegexPattern@f4ecb23, Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Esamina tutti gli elementi <Pattern> nel file XML del criterio di protezione delle espressioni regolari non riuscito. Controlla se uno degli elementi <Pattern> contiene un'espressione regolare non valida. Se uno degli elementi <Pattern> contiene un'espressione regolare non valida, questa è la causa dell'errore.

    Ad esempio, il seguente criterio consente di specificare il valore Pattern> di foo){2}, che è considerato un'espressione regolare non valida: 

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <URIPath>
            <Pattern>foo){2}</Pattern>
        </URIPath>
        <Source>request</Source>
    </RegularExpressionProtection>

    Nell'esempio riportato sopra, l'espressione regolare specificata in <Pattern> manca di una parentesi di apertura. Pertanto, viene considerata un'espressione regolare non valida. Di conseguenza, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che ogni elemento <Pattern> del criterio RegularExpressionProtection contenga un'espressione regolare valida. Puoi cercare diversi strumenti regex online o offline per il debug delle espressioni regolari. Per correggere il criterio di protezione delle espressioni regolari di esempio mostrato sopra, aggiungi le parentesi mancanti:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <URIPath>
            <Pattern>(foo){2}</Pattern>
        </URIPath>
        <Source>request</Source>
    </RegularExpressionProtection>

XPathCompilationFailed

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Failed to compile xpath xpath_expression. Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

Messaggio di errore di esempio

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile xpath /notapigee:foo/notapigee:bar. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

Screenshot di errore di esempio

Testo dell&#39;errore XPathCompilationFailed

Causa

Se il prefisso o il valore utilizzato nell'elemento <XPath> non fa parte di nessuno degli spazi dei nomi dichiarati nel criterio di protezione delle espressioni regolari, il deployment del proxy API non va a buon fine.

Puoi trovare ulteriori informazioni su spazi dei nomi, XPath e prefisso in Spazi dei nomi XML e come influiscono su XPath e XSLT.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore e l'espressione XPath utilizzata. Puoi trovare entrambi questi elementi nel messaggio di errore.

    Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1 e l'espressione XPath è /notapigee:foo/notapigee:bar:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile xpath /notapigee:foo/notapigee:bar. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione delle espressioni regolari non riuscito, verifica che l'XPath impostato nell'elemento Expression corrisponda a quello identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica l'XPath come /notapigee:foo/notapigee:bar, che corrisponde al contenuto del messaggio di errore:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
     <XMLPayload>
         <Namespaces>
             <Namespace prefix="apigee">http://www.apigee.com</Namespace>
         </Namespaces>
         <XPath>
             <Expression>/notapigee:foo/notapigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>
  3. Esamina gli elementi <Namespaces> e <Expression> nel criterio RegularExpressionProtection. Se lo specifico <Expression> indicato nel messaggio di errore utilizza un prefisso o un valore che non fa parte degli spazi dei nomi dichiarati nel criterio RegularExpressionProtection, è questo la causa dell'errore.

    Tieni presente che <XPath> specifico utilizza il prefisso notapigee nel criterio RegularExpressionProtection di esempio:

    <Expression>/notapigee:foo/notapigee:bar</Expression>

    Tuttavia, il prefisso notapigee non è definito in nessuno degli elementi <Namespace>. pertanto la compilazione di <XPath> non va a buon fine e porta a un errore del deployment.

Risoluzione

Assicurati che tutti gli spazi dei nomi utilizzati negli elementi <Expression> sotto gli elementi <XPath> siano dichiarati nel criterio RegularExpressionProtection. Per correggere l'esempio riportato sopra, puoi sostituire il prefisso notapigee con apigee, che è dichiarato negli spazi dei nomi:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
     <XMLPayload>
         <Namespaces>
             <Namespace prefix="apigee">http://www.apigee.com</Namespace>
         </Namespaces>
         <XPath>
             <Expression>/apigee:foo/apigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>

CannotBeConvertedToNodeset

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Result of xpath xpath_expression cannot be converted to nodeset. Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

Messaggio di errore di esempio

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Result of xpath count(//apigee:foo) cannot be converted to nodeset. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

Screenshot di errore di esempio

Testo dell&#39;errore CanBeConversionsToNodeset

Causa

Se il criterio per le espressioni regolari ha un'espressione <XPath> in cui l'elemento <Type> è definito come nodeset, ma l'espressione non può essere convertita in nodeset, il deployment del proxy API non riuscirà.

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e l'espressione XPath che non può essere convertita in nodeset. Puoi trovare entrambi questi elementi nel messaggio di errore.

    Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1 e l'espressione XPath è count(//apigee:foo):

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Result of xpath count(//apigee:foo) cannot be converted to nodeset. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione dalle espressioni regolari con errori, verifica che l'XPath impostato nell'elemento <Expression> dell'elemento <XPath> corrisponda all'XPath identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, la seguente norma specifica il valore count(//apigee:foo), che corrisponde a quello indicato nel messaggio di errore:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <Source>request</Source>
         <XMLPayload>
             <Namespaces>
                 <Namespace prefix="apigee">http://www.apigee.com</Namespace>
             </Namespaces>
             <XPath>
                 <Expression>count(//apigee:foo)</Expression>
                 <Type>nodeset</Type>
                 <Pattern>pattern</Pattern>
                 <Pattern>pattern2</Pattern>
             </XPath>
         </XMLPayload>
    </RegularExpressionProtection>

  3. Esamina il valore impostato nell'elemento <Type> sotto l'elemento <XPath>. Se l'elemento <Type> è nodeset, questa è la causa dell'errore.

    In questo esempio, l'espressione XPath è count() che non restituisce uno o più nodi. Pertanto, il deployment del proxy API non va a buon fine.

Risoluzione

Se l'elemento <Type> è impostato su nodeset, assicurati che il risultato dell'elemento <Expression> impostato in <XPath> sia costituito da uno o più nodi. In alternativa, modifica l'elemento <Type> in base a un valore più appropriato in base al tuo caso d'uso.

Per correggere l'esempio precedente, puoi modificare l'elemento <Expression> in modo che assuma un valore diverso che può restituire i nodi:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
     <XMLPayload>
         <Namespaces>
             <Namespace prefix="apigee">http://www.apigee.com</Namespace>
         </Namespaces>
         <XPath>
             <Expression>/apigee:foo/apigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>

JSONPathCompilationFailed

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Deploying Revision revision_number to environment
RegularExpressionProtection policy_name: Failed to compile jsonpath jsonpath_expression Context Revision:revision_number;APIProxy:RegexThreat;Organization:organization;Environment:environment.

Messaggio di errore di esempio

Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile jsonpath $.store.book[*.author. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

Screenshot di esempio di errore

Testo di errore JSONPathCompilationFailed

Causa

Se l'elemento <Expression> in <JSONPath> di un criterio di protezione dalle espressioni regolari è impostato su un'espressione JSONPath non valida, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore e l'espressione JSONPath non valida utilizzata. Puoi trovare entrambi questi elementi nel messaggio di errore.

    Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1 e l'espressione JSONPath è $.store.book[*.author:

    Error Deploying Revision 1 to test
RegularExpressionProtection Regular-Expression-Protection-1: Failed to compile jsonpath $.store.book[*.author. Context Revision:1;APIProxy:RegexThreat;Organization:myorg;Environment:test.

  2. Nel file XML del criterio di protezione tramite espressioni regolari non riuscito, verifica che il valore JSONPath impostato nell'elemento Expression corrisponda a quello identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica l'elemento Expression nell'elemento <JSONPath> come $.store.book[*.author, che corrisponde al contenuto del messaggio di errore:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <Source>request</Source>
        <JSONPayload>
             <JSONPath>
                 <Expression>$.store.book[*.author</Expression>
                 <Pattern>REGEX PATTERN</Pattern>
                 <Pattern>REGEX PATTERN</Pattern>
             </JSONPath>
            </JSONPayload>
    </RegularExpressionProtection>

  3. Esamina l'elemento <Expression> all'interno dell'elemento <JSONPath> nel criterio. Se non corrisponde alla sintassi JSONPath, è questa la causa dell'errore. Nell'esempio precedente manca la parentesi quadra di chiusura, il che rende l'espressione non valida.

    Poiché l'espressione di percorso JSON non è valida, il deployment del proxy API ha esito negativo.

Risoluzione

Assicurati che il valore dell'elemento <Expression> all'interno dell'elemento <JSONPath> nel criterio di protezione delle espressioni regolari sia un'espressione JSONPath valida.

Per correggere l'esempio mostrato sopra, puoi aggiungere la parentesi quadra di chiusura mancante al valore dell'elemento <Expression>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
    <JSONPayload>
         <JSONPath>
             <Expression>$.store.book[*].author</Expression>
             <Pattern>REGEX PATTERN</Pattern>
             <Pattern>REGEX PATTERN</Pattern>
         </JSONPath>
        </JSONPayload>
</RegularExpressionProtection>

NothingToEnforce

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.

Screenshot di errore di esempio

Testo errore NothingToEnforce

Causa

Se il criterio RegularExpressionProtection non contiene nessuno degli elementi <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, il deployment dell'API Proxy non va a buon fine.

Come indicato nel messaggio di errore, il criterio RegularExpressionProtection deve includere almeno uno dei seguenti elementi: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore. Puoi trovarlo nel messaggio di errore. Ad esempio, nell'errore seguente , il nome del criterio è Regular-Expression-Protection-1:

    RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.

  2. Esamina il criterio di protezione delle espressioni regolari non riuscito (identificato nel passaggio 1 qui sopra). Se il criterio non contiene nemmeno uno dei seguenti elementi: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, è questa la causa dell'errore.

    Ad esempio, la seguente norma di protezione tramite espressioni regolari non contiene nessuno degli elementi sopra menzionati:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
        <DisplayName>Regular Expression Protection-1</DisplayName>
        <Properties/>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
        <Source>request</Source>
    </RegularExpressionProtection>

    Poiché nessuno degli elementi obbligatori è presente nel criterio Estrai variabili, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia almeno uno di questi elementi obbligatori: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>. Ad esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
    <DisplayName>Regular Expression Protection-1</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
    <JSONPayload>
        <JSONPath>
            <Expression>$.store.book[*].author</Expression>
            <Pattern>REGEX PATTERN</Pattern>
            <Pattern>REGEX PATTERN</Pattern>
        </JSONPath>
    </JSONPayload>
</RegularExpressionProtection>

NoPatternsToEnforce

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: No patterns to enforce in payload_name.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.

Screenshot di errore di esempio

Testo errore NoPatternsToEnforce

Causa

Se uno degli elementi di primo livello (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>) non ha l'elemento <Pattern> definito nel Regolamento di protezione delle espressioni regolari, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il nome del criterio RegularExpressionProtection in cui si è verificato l'errore e l'elemento secondario che non ha l'elemento <Pattern>. Puoi trovare entrambi questi elementi nel messaggio di errore.

    Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1 e l'elemento secondario è XPath:

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Esamina il criterio di protezione delle espressioni regolari con errori e verifica se l'elemento secondario identificato nel passaggio 1 non contiene l'elemento <Pattern>. Se l'elemento <Pattern> non esiste al suo interno, allora è la causa dell'errore.

    Ad esempio, il seguente criterio non ha l'elemento <Pattern> all'interno di <XPath>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

    Poiché l'elemento <XPath> non ha l'elemento <Pattern>, il deployment del proxy API non va a buon fine.

Risoluzione

Assicurati che uno degli elementi <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload> abbia almeno un <Pattern> specificato. Per informazioni su come specificare correttamente l'elemento, consulta le norme relative alla protezione tramite espressioni regolari.

Per correggere l'esempio precedente, possiamo semplicemente aggiungere l'elemento <Pattern> all'elemento <XPath> sotto <XMLPayload>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

NONEmptyPrefixMappedToEmptyURI

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Non-empty prefix prefix_name cannot be mapped to empty uri.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.

Screenshot di errore di esempio

Testo dell&#39;errore NONEmptyPrefixMappedToEmptyURI

Causa

Questo errore si verifica se il criterio RegularExpressionProtection ha un prefisso definito nell'elemento <Namespace> sotto l'elemento <XMLPayload>, ma non è definito alcun URI.

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e il nome del prefisso che non è mappato all'URI. Puoi trovare entrambe le voci nel messaggio di errore.

    Ad esempio, nel seguente errore, il nome del criterio è Regular Expression Protection-1 e il prefisso è apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.

  2. Nel file XML del criterio di protezione dalle espressioni regolari che non ha superato i controlli, verifica che il nome del prefisso impostato nell'elemento <Namespace> sotto l'elemento <XMLPayload> corrisponda al nome del prefisso identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica un prefisso denominato apigee nell'elemento <Namespace>, che corrisponde a quello indicato nel messaggio di errore:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee"/>
          <Namespace prefix="gmail">http://mail.google.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

  3. Verifica che l'elemento <Namespace> con il prefisso specifico identificato nel passaggio 2 abbia un URI valido. Se manca l'URI, questo è la causa dell'errore.

    Nel criterio di protezione delle espressioni regolari di esempio mostrato sopra, tieni presente che non esiste un URI corrispondente all'elemento <Namespace> con il prefisso apigee; perciò viene visualizzato l'errore:

    Non-empty prefix apigee cannot be mapped to empty uri.

Risoluzione

Assicurati che tutti gli elementi <Namespace> definiti con un prefisso abbiano un URI corrispondente nel criterio Estrai variabili. Ad esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
      <Namespace prefix="gmail">http://mail.google.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

DuplicatePrefix

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.

Screenshot di errore di esempio

Testo dell&#39;errore di prefisso duplicato

Causa

Questo errore si verifica se il criterio RegularExpressionProtection ha lo stesso prefisso definito più di una volta nell'elemento <Namespace> sotto l'elemento <XMLPayload>.

Ad esempio, questo errore si verifica perché il prefisso apigee è definito due volte, come mostrato di seguito: 

<Namespace prefix="apigee">http://www.apigee.com</Namespace>
<Namespace prefix="apigee">http://www.apigee.com</Namespace>

Diagnosi

  1. Identifica il criterio RegularExpressionProtection in cui si è verificato l'errore e il nome del prefisso. Puoi trovare entrambi questi elementi nel messaggio di errore.

    Ad esempio, nel seguente errore, il nome del criterio è Regular Expression Protection-1 e il prefisso è apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.

  2. Nel file XML del criterio di protezione dalle espressioni regolari che non ha superato i controlli, verifica che il nome del prefisso impostato nell'elemento <Namespace> sotto l'elemento <XMLPayload> corrisponda al nome del prefisso identificato nel messaggio di errore (passaggio 1 sopra).

    Ad esempio, il seguente criterio specifica un prefisso denominato apigee nell'elemento <Namespace> , che corrisponde al contenuto del messaggio di errore:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

  3. Determina se l'elemento <Namespace> con il prefisso specifico identificato nel passaggio 2 è stato definito più di una volta. Se viene definito più di una volta, ciò è la causa dell'errore.

    Nel criterio di protezione delle espressioni regolari di esempio mostrato sopra, tieni presente che l'elemento <Namespace> con il prefisso apigee è stato definito due volte. Di conseguenza, viene visualizzato l'errore:

    Duplicate prefix apigee.

Risoluzione

Assicurati che esista una sola definizione per ogni prefisso negli elementi <Namespace> del criterio RegularExpressionProtection. Ad esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <XMLPayload>
        <Namespaces>
          <Namespace prefix="apigee">http://www.apigee.com</Namespace>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

EmptyXPathExpression

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.

Screenshot di errore di esempio

Testo dell&#39;errore EmptyXPathExpression

Causa

Se il criterio RegularExpressionProtection non ha un elemento <Expression> impostato all'interno dell'elemento <XPath>, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il criterio di protezione delle espressioni regolari non riuscito dal messaggio di errore. Ad esempio, nel seguente errore, il nome del criterio è Protezione-per-espressioni-regolari-1:

    RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.

  2. Nel file XML del criterio di protezione dalle espressioni regolari non riuscito, determina se è presente un elemento <XMLPayload> con elemento secondario <XPath> in cui non è definito alcun elemento <Expression> o l'elemento <Expression> non è impostato su alcun valore. In questo caso, è la causa dell'errore.

    Ad esempio, di seguito è riportato un criterio di protezione dalle espressioni regolari con un elemento <XMLPayload>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression></Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

    Poiché all'interno dell'elemento <XPath> è presente un elemento <Expression> vuoto, il deployment dell'API Proxy non va a buon fine.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia un elemento <Expression> non vuoto e valido definito nell'elemento <XPath>. Ad esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <XMLPayload>
    <Namespaces>
      <Namespace prefix="apigee">http://www.apigee.com</Namespace>
    </Namespaces>
    <XPath>
      <Expression>/apigee:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

EmptyJSONPathExpression

Messaggio di errore

Il deployment del proxy API tramite l'API o l'interfaccia utente di Apigee non va a buon fine con questo messaggio di errore:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Messaggio di errore di esempio

Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.

Screenshot di esempio di errore

Testo dell&#39;errore EmptyJSONPathExpression

Causa

Se il criterio RegularExpressionProtection non ha un elemento <Expression> impostato all'interno dell'elemento <JSONPath>, il deployment del proxy API non va a buon fine.

Diagnosi

  1. Identifica il criterio di protezione dalle espressioni regolari non superato dal messaggio di errore. Ad esempio, nell'errore seguente, il nome del criterio è Regular-Expression-Protection-1:

    Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.

  2. Nel file XML del criterio di protezione dalle espressioni regolari non riuscito, determina se è presente un elemento <JSONPayload> con elemento secondario <JSONPath> in cui non è definito alcun elemento <Expression> o l'elemento <Expression> non è impostato su alcun valore. In questo caso, è la causa dell'errore.

    Ad esempio, di seguito è riportato un criterio di protezione dalle espressioni regolari con un elemento <JSONPayload>:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
      <DisplayName>Regular Expression Protection-1</DisplayName>
      <Properties/>
      <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
      <Source>request</Source>
      <JSONPayload>
        <JSONPath>
          <Expression></Expression>
          <Pattern>REGEX PATTERN</Pattern>
          <Pattern>REGEX PATTERN</Pattern>
        </JSONPath>
      </JSONPayload>
    </RegularExpressionProtection>

    Poiché all'interno dell'elemento <JSONPath> è presente un elemento <Expression> vuoto, il deployment dell'API Proxy non va a buon fine.

Risoluzione

Assicurati che il criterio RegularExpressionProtection abbia un elemento <Expression> valido e non vuoto definito sotto l'elemento <JSONPath>. Ad esempio:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
  <DisplayName>Regular Expression Protection-1</DisplayName>
  <Properties/>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <Source>request</Source>
  <JSONPayload>
    <JSONPath>
      <Expression>$.store.book[*].author</Expression>
      <Pattern>REGEX PATTERN</Pattern>
      <Pattern>REGEX PATTERN</Pattern>
    </JSONPath>
  </JSONPayload>
</RegularExpressionProtection>