Solución de problemas de errores en la implementación de la política de protección de expresiones regulares

Estás viendo la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

InvalidRegularExpression

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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.

Ejemplo de mensaje de error

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.

Captura de pantalla de error de ejemplo

Texto de error de InvalidRegularExpression

Causa

Si la expresión regular del elemento <Pattern> de la política RegularExpressionProtection no es válida, la implementación del proxy de API falla.

Diagnóstico

Identifica el nombre de la política RegularExpressionProtection del mensaje de error. Por ejemplo, en el siguiente error, el nombre de la Política RegularExpressionProtection es 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.

Examina todos los elementos <Pattern> del archivo XML de la política de protección de expresiones regulares con errores. Verifica si alguno de los elementos <Pattern> tiene una expresión regular no válida. Si alguno de los elementos <Pattern> tiene una expresión regular no válida, esa es la causa del error.

Por ejemplo, la siguiente política especifica el valor de Pattern> de foo){2}, que se considera una expresión regular no válida:
```
<?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>
```
En el ejemplo anterior, la expresión regular que se especifica en <Pattern> tiene los paréntesis de apertura faltantes. Por lo tanto, se la considera una expresión regular no válida. Por lo tanto, la implementación del proxy de API falla.

Solución

Asegúrate de que cada elemento <Pattern> de la política RegularExpressionProtection contenga una expresión regular válida. Puedes buscar diferentes herramientas de regex en línea o sin conexión para depurar tus expresiones regulares. Para corregir la política de protección de expresiones regulares anterior, agrega los paréntesis que faltan:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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.

Ejemplo de mensaje de error

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.

Captura de pantalla de error de ejemplo

Texto de error de XPathCompilationFailed

Causa

Si el prefijo o el valor que se usó en el elemento <XPath> no forma parte de los espacios de nombres declarados en la política RegularExpressionProtection, la implementación del proxy de API falla.

Puede encontrar más información sobre los espacios de nombres, la XPath y el prefijo en Espacios de nombres XML y cómo afectan las XPath y XSLT.

Diagnóstico

Identifica el nombre de la política RegularExpressionProtection en el que se generó el error y la expresión XPath que se usó. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1 y la expresión XPath es /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.
```

En el XML de la política de protección de expresiones regulares con errores, verifica que la XPath establecida en el elemento Expression coincida con la XPath que se identificó en el mensaje de error (paso n.º 1 anterior).

Por ejemplo, en la siguiente política, se especifica la XPath como /notapigee:foo/notapigee:bar, que coincide con el contenido del mensaje de error:

<?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>

Examina los elementos <Namespaces> y <Expression> en la política RegularExpressionProtection. Si la <Expression> específica que se indica en el mensaje de error usa un prefijo o valor que no forma parte de los espacios de nombres declarados en la política RegularExpressionProtection, esa es la causa del error.
Ten en cuenta que la <XPath> específica usa el prefijo notapigee en el ejemplo de la política RegularExpressionProtection:
```
<Expression>/notapigee:foo/notapigee:bar</Expression>
```
Sin embargo, el prefijo notapigee no se define en ninguno de los elementos <Namespace>. Por lo tanto, la compilación de <XPath> falla lo que da lugar a un error de implementación.

Solución

Asegúrate de que todos los espacios de nombres que se usan en los elementos <Expression>, en los elementos <XPath>, se declaren en la política RegularExpressionProtection. Para corregir el ejemplo anterior, podrías reemplazar el prefijo notapigee por apigee, que se declara en los espacios de nombres:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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.

Ejemplo de mensaje de error

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.

Captura de pantalla de error de ejemplo

Texto de error CannotBeConvertedToNodeset

Causa

Si la política de expresión regular tiene una expresión <XPath> en la que el elemento <Type> se define como nodeset, pero la expresión no se puede convertir en un conjunto de nodos, la implementación del proxy de API falla.

Diagnóstico

Identifica la política RegularExpressionProtection en la que se produjo el error y la expresión XPath que no se puede convertir en el conjunto de nodos. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1 y la expresión XPath es 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.
```

En el XML de la política de protección de expresiones regulares con errores, verifica que la XPath establecida en el elemento <Expression> del elemento <XPath> coincida con la XPath que se identificó en el mensaje de error (paso n.º 1 anterior).

Por ejemplo, la siguiente política especifica el elemento count(//apigee:foo), que coincide con el contenido del mensaje de error:

<?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>

Examina el valor establecido en el elemento <Type> debajo del elemento <XPath>. Si el elemento <Type> es nodeset, esa es la causa del error.

En este ejemplo, la expresión de XPath es count() que no muestra uno o más nodos. Por lo tanto, la implementación del proxy de API falla.

Solución

Si se configura el elemento <Type> en el conjunto de nodos, asegúrate de que el resultado del elemento <Expression> configurado como <XPath> sea uno o más nodos. También puedes cambiar el elemento <Type> por un valor más apropiado según tu caso de uso.

Para solucionar el ejemplo anterior, puedes cambiar el elemento <Expression> por un valor diferente que pueda mostrar nodos:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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.

Ejemplo de mensaje de error

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.

Captura de pantalla de error de ejemplo

Texto de error JSONPathCompilationFailed

Causa

Si el elemento <Expression> en el elemento <JSONPath> de una política de protección de expresiones regulares se establece en una expresión JSONPath no válida, la implementación del proxy de API falla.

Diagnóstico

Identifica el nombre de la Política RegularExpressionProtection en el que se generó el error y se usó la expresión JSONPath no válida. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1 y la expresión JSONPath es $.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.
```

En el XML de la política de protección de expresiones regulares con errores, verifica que la JSONPath configurada en el elemento Expression coincida con la JSONPath que se identificó en el mensaje de error (paso n.º 1 anterior).

Por ejemplo, la siguiente política especifica el elemento Expression en el elemento <JSONPath> como $.store.book[*.author, que coincide con el contenido del mensaje de error:

<?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>

Examina el elemento <Expression> en el elemento <JSONPath> de la política. Si no coincide con la sintaxis JSONPath, esta es la causa del error. En el ejemplo anterior, falta el corchete de cierre, lo que genera que la expresión no sea válida.

Dado que la expresión de ruta JSON no es válida, la implementación del proxy de API falla.

Solución

Asegúrate de que el valor del elemento <Expression> dentro del elemento <JSONPath> en la política de protección de expresiones regulares sea una expresión JSONPath válida.

Para corregir el ejemplo anterior, puedes agregar el corchete de cierre que falta al valor del 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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error NothingToEnforce

Causa

Si la Política RegularExpressionProtection no tiene ningún elemento <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, la implementación del proxy de API falla.

Como se indica en el mensaje de error, la Política RegularExpressionProtection debe tener al menos uno de estos elementos incluidos en la política: <URIPath>, <QueryParam>, <Header>, <FormParam>. <XMLPayload> o <JSONPayload>.

Diagnóstico

Identifica el nombre de la Política RegularExpressionProtection en la que se produjo el error. Puedes encontrarlo en el mensaje de error. Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1:
```
RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.
```
Examina la política de protección de expresiones regulares con errores (identificada en el paso n.º 1 anterior). Si la política no tiene ni siquiera uno de los siguientes elementos: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>, esa es la causa del error.

Por ejemplo, la siguiente política de Protección de expresiones regulares no tiene ninguno de los elementos mencionados antes:
```
<?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>
```
Dado que ninguno de los elementos obligatorios está presente en la política de Extracción de variables, la implementación del proxy de API falla.

Solución

Asegúrate de que la Política RegularExpressionProtection tenga al menos uno de estos elementos obligatorios: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>. Por ejemplo:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error NoPatternsToEnforce

Causa

Si alguno de los elementos de nivel superior (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload>) no tiene el elemento <Pattern> definido en la Política RegularExpressionProtection, la implementación del proxy de API falla.

Diagnóstico

Identifica el nombre de la política RegularExpressionProtection en el que se produjo el error y el elemento secundario que no tiene el elemento <Pattern>. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1 y el elemento secundario es XPath:
```
RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
```

Examina la política de protección de expresiones regulares con errores y verifica si el elemento secundario que se identificó en el paso n.º 1 no tiene el elemento <Pattern>. Si el elemento <Pattern> no existe en esa carpeta, esa es la causa del error.

Por ejemplo, la siguiente política no tiene un elemento <Pattern> dentro de <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>

Dado que el elemento <XPath> no tiene el elemento <Pattern>, la implementación del proxy de API falla.

Solución

Asegúrate de que todos los elementos <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> o <JSONPayload> tengan, al menos, un <Pattern> especificado. Consulta la Política RegularExpressionProtection para obtener información sobre cómo especificar el elemento de forma correcta.

Para corregir el ejemplo anterior, podríamos agregar el elemento <Pattern> al elemento <XPath> debajo de <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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

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

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error NONEmptyPrefixMappedToEmptyURI

Causa

Este error se produce si la Política RegularExpressionProtection tiene un prefijo definido en el elemento <Namespace> debajo del elemento <XMLPayload>, pero no se define un URI.

Diagnóstico

Identifica la política RegularExpressionProtection en el que se produjo el error y el nombre del prefijo que no se asignó al URI. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular Expression Protection-1 y el prefijo es Apigee:
```
RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.
```

En el archivo XML de la política de protección de expresiones regulares, verifica que el nombre del prefijo establecido en el elemento <Namespace> correspondiente al elemento <XMLPayload> coincida con el nombre del prefijo que se identificó en el mensaje de error (paso n.º 1 anterior).

Por ejemplo, en la siguiente política se especifica un prefijo llamado apigee en el elemento <Namespace>, que coincide con el contenido del mensaje de error:

<?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>

Valida si el elemento <Namespace> con el prefijo específico identificado en el paso n.º 2 tiene un URI válido. Si falta el URI, esa es la causa del error.

En la política de protección de expresiones regulares anterior, ten en cuenta que no hay un URI que corresponda al elemento <Namespace> con el prefijo apigee. Por lo tanto, verás el siguiente error:
```
Non-empty prefix apigee cannot be mapped to empty uri.
```

Solución

Asegúrate de que todos los elementos <Namespace> definidos con un prefijo tengan el URI correspondiente en la política de extracción de variables. Por ejemplo:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error de DuplicatePrefix

Causa

Este error se genera si la política RegularExpressionProtection tiene el mismo prefijo definido más de una vez en el elemento <Namespace> debajo del elemento <XMLPayload>.

Por ejemplo, este error se produce, ya que el prefijo apigee se define dos veces como se muestra a continuación:

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

Diagnóstico

Identifica la Política RegularExpressionProtection en la que se produjo el error y el nombre del prefijo. Puedes encontrar ambos elementos en el mensaje de error.

Por ejemplo, en el siguiente error, el nombre de la política es Regular Expression Protection-1 y el prefijo es Apigee:
```
RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.
```

Por ejemplo, en la siguiente política se especifica un prefijo llamado apigee en el elemento <Namespace>, que coincide con el contenido del mensaje de error:

<?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>

Determina si el elemento <Namespace> con el prefijo específico, que se identificó en el paso n.º 2, se definió más de una vez. Si es así, esa es la causa del error.

En la política de protección de expresiones regulares que se muestra antes, observa que el elemento <Namespace> con el prefijo apigee se definió dos veces. Por lo tanto, verás el siguiente error:
```
Duplicate prefix apigee.
```

Solución

Asegúrate de que solo haya una definición para cada prefijo en los elementos <Namespace> en la política RegularExpressionProtection. Por ejemplo:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error EmptyXPathExpression

Causa

Si la política RegularExpressionProtection no tiene un elemento <Expression> establecido en el elemento <XPath>, la implementación del proxy de API falla.

Diagnóstico

Identifica la política de protección de expresiones regulares con errores del mensaje de error. Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1:
```
RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.
```

En el XML de la política de protección de expresiones regulares con errores, determina si hay un elemento <XMLPayload> con el elemento secundario <XPath> que no tenga un elemento <Expression> definido o que el elemento <Expression> no esté establecido en ningún valor. Si es así, esa es la causa del error.

Por ejemplo, esta es una política de protección de expresiones regulares 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>

Dado que hay un elemento <Expression> vacío dentro del elemento <XPath>, la implementación del proxy de API falla.

Solución

Asegúrate de que la política RegularExpressionProtection tenga un elemento <Expression> que no esté vacío y que sea válido definido en el elemento <XPath>. Por ejemplo:

<?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

Mensaje de error

Si la implementación del proxy de API a través de la IU de Apigee o la API falla, mostrará con este mensaje de error:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Ejemplo de mensaje de error

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

Captura de pantalla de error de ejemplo

Texto de error EmptyJSONPathExpression

Causa

Si la política RegularExpressionProtection no tiene un elemento <Expression> establecido en el elemento <JSONPath>, la implementación del proxy de API falla.

Diagnóstico

Identifica la política de protección de expresiones regulares con errores del mensaje de error. Por ejemplo, en el siguiente error, el nombre de la política es Regular-Expression-Protection-1:
```
Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.
```

En el XML de la política de protección de expresiones regulares con errores, determina si hay un elemento <JSONPayload> con el elemento secundario <JSONPath> que no tenga un elemento <Expression> definido o que el elemento <Expression> no esté establecido en ningún valor. Si es así, esa es la causa del error.

Por ejemplo, esta es una política de protección de expresiones regulares que tiene 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>

Dado que hay un elemento <Expression> vacío dentro del elemento <JSONPath>, la implementación del proxy de API falla.

Solución

Asegúrate de que la política RegularExpressionProtection tenga un elemento <Expression> que no esté vacío y que sea válido definido en el elemento <JSONPath>. Por ejemplo:

<?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>