Устранение ошибок развертывания политики защиты регулярных выражений

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

Недопустимое регулярное выражение

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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.

Пример сообщения об ошибке

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.

Пример скриншота ошибки

Текст ошибки InvalidRegularExpression

Причина

Если регулярное выражение в элементе <Pattern> политики RegularExpressionProtection недействительно, развертывание API-прокси завершится неудачей.

Диагноз

  1. Найдите в сообщении об ошибке имя политики RegularExpressionProtection . Например, в следующем сообщении об ошибке имя политики RegularExpressionProtectionRegular-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. Проверьте все элементы <Pattern> в XML-файле политики защиты от регулярных выражений, в котором произошла ошибка. Убедитесь, что ни один из элементов <Pattern> не содержит недопустимого регулярного выражения. Если какой-либо из элементов <Pattern> содержит недопустимое регулярное выражение, то это и является причиной ошибки.

    Например, следующая политика указывает значение Pattern> of foo){2} , которое считается недопустимым регулярным выражением:

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

    В приведенном выше примере в регулярном выражении, указанном в <Pattern> отсутствует открывающая скобка. Следовательно, оно считается недопустимым регулярным выражением. Поэтому развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что каждый элемент <Pattern> в политике RegularExpressionProtection содержит допустимое регулярное выражение. Для отладки регулярных выражений можно использовать различные онлайн или офлайн инструменты. Чтобы исправить приведенный выше пример политики защиты от регулярных выражений, добавьте недостающие скобки:

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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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.

Пример сообщения об ошибке

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.

Пример скриншота ошибки

Текст ошибки XPathCompilationFailed

Причина

Если префикс или значение, используемое в элементе <XPath> , не входит ни в одно из объявленных пространств имен в политике RegularExpressionProtection , то развертывание API-прокси завершится неудачей.

Более подробную информацию о пространствах имен, XPath и префиксах можно найти в статье «Пространства имен XML и их влияние на XPath и XSLT» .

Диагноз

  1. Укажите имя политики RegularExpressionProtection , в которой произошла ошибка, и использованное выражение XPath. Оба эти элемента можно найти в сообщении об ошибке.

    Например, в следующей ошибке имя политики — Regular-Expression-Protection-1 , а выражение 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. В XML-файле политики защиты от регулярных выражений, в котором произошел сбой, убедитесь, что XPath, заданный в элементе Expression совпадает с XPath, указанным в сообщении об ошибке (шаг № 1 выше).

    Например, следующая политика указывает XPath как /notapigee:foo/notapigee:bar , что соответствует содержимому сообщения об ошибке:

    <?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. Проверьте элементы <Namespaces> и <Expression> в политике RegularExpressionProtection . Если указанное в сообщении об ошибке выражение <Expression> использует префикс или значение, не входящее в пространства имен, объявленные в политике RegularExpressionProtection , то это и является причиной ошибки.

    Обратите внимание, что в примере политики RegularExpressionProtection в конкретном <XPath> используется префикс notapigee :

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

    Однако префикс notapigee не определен ни в одном из элементов <Namespace> ; следовательно, компиляция <XPath> завершается с ошибкой, что приводит к сбою развертывания.

Разрешение

Убедитесь, что все пространства имен, используемые в элементах <Expression> внутри элементов <XPath> , объявлены в политике RegularExpressionProtection . Чтобы исправить приведенный выше пример, вы можете заменить префикс notapigee на apigee , который объявлен в пространствах имен:

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

Невозможно преобразовать в набор узлов

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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.

Пример сообщения об ошибке

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.

Пример скриншота ошибки

Текст ошибки CannotBeConvertedToNodeset

Причина

Если в политике регулярных выражений содержится выражение <XPath> , в котором элемент <Type> определен как nodeset , но выражение не может быть преобразовано в nodeset, то развертывание API-прокси завершится неудачей.

Диагноз

  1. Определите политику RegularExpressionProtection , в которой произошла ошибка, и выражение XPath, которое не может быть преобразовано в набор узлов. Оба эти элемента можно найти в сообщении об ошибке.

    Например, в следующей ошибке имя политики — Regular-Expression-Protection-1 , а выражение 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. В XML-файле политики защиты от регулярных выражений, в котором произошел сбой, убедитесь, что XPath, заданный в элементе <Expression> элемента <XPath> , совпадает с XPath, указанным в сообщении об ошибке (шаг #1 выше).

    Например, следующая политика задает значение как count(//apigee:foo) , что соответствует содержимому сообщения об ошибке:

    <?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. Проверьте значение, заданное в элементе <Type> , расположенном под элементом <XPath> . Если элемент <Type> имеет nodeset , то это и является причиной ошибки.

    В этом примере выражение XPath — count() , которое не возвращает ни одного, ни нескольких узлов. Поэтому развертывание API-прокси завершается неудачей.

Разрешение

Если для элемента <Type> установлено значение nodeset, убедитесь, что результатом действия элемента <Expression> , заданного в <XPath> является один или несколько узлов. В качестве альтернативы измените значение элемента <Type> на более подходящее в зависимости от вашего сценария использования.

Чтобы исправить приведенный выше пример, можно изменить значение элемента <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>
     <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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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.

Пример сообщения об ошибке

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.

Пример скриншота ошибки

Текст ошибки JSONPathCompilationFailed

Причина

Если элемент <Expression> в элементе <JSONPath> политики защиты на основе регулярных выражений задан на недопустимое выражение JSONPath, то развертывание API-прокси завершится неудачей.

Диагноз

  1. Укажите имя политики RegularExpressionProtection , в которой произошла ошибка и было использовано недопустимое выражение JSONPath. Оба эти момента можно найти в сообщении об ошибке.

    Например, в следующем сообщении об ошибке имя политики — Regular-Expression-Protection-1 , а выражение 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. В XML-файле политики защиты от регулярных выражений, в котором произошел сбой, убедитесь, что JSONPath, заданный в элементе Expression совпадает с JSONPath, указанным в сообщении об ошибке (шаг № 1 выше).

    Например, следующая политика указывает элемент Expression в элементе <JSONPath> как $.store.book[*.author , что соответствует содержимому сообщения об ошибке:

    <?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. Проверьте элемент <Expression> в элементе <JSONPath> политики. Если он не соответствует синтаксису JSONPath, то это и является причиной ошибки. В приведенном выше примере отсутствует закрывающая квадратная скобка, что делает выражение недействительным.

    Поскольку выражение JSON Path Expression недействительно, развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что значение элемента <Expression> внутри элемента <JSONPath> в политике защиты от регулярных выражений является допустимым выражением JSONPath.

Чтобы исправить приведенный выше пример, можно добавить отсутствующую закрывающую квадратную скобку к значению элемента <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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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

Пример сообщения об ошибке

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

Пример скриншота ошибки

Текст ошибки NothingToEnforce

Причина

Если политика RegularExpressionProtection не содержит ни одного из элементов <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <JSONPayload> , развертывание API-прокси завершится неудачей.

Как указано в сообщении об ошибке, политика RegularExpressionProtection должна содержать как минимум один из следующих элементов: <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <JSONPayload> .

Диагноз

  1. Укажите имя политики RegularExpressionProtection, в которой произошла ошибка. Вы можете найти его в сообщении об ошибке. Например, в следующем сообщении об ошибке имя политики — Regular-Expression-Protection-1:

    RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.
  2. Проверьте политику защиты от регулярных выражений, которая не сработала (выявленную на шаге №1 выше). Если в политике отсутствует хотя бы один из следующих элементов: <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <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>
        </RegularExpressionProtection>

    Поскольку ни один из обязательных элементов не присутствует в политике извлечения переменных, развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что политика RegularExpressionProtection содержит хотя бы один из следующих обязательных элементов: <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <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>$.store.book[*].author</Expression>
            <Pattern>REGEX PATTERN</Pattern>
            <Pattern>REGEX PATTERN</Pattern>
        </JSONPath>
    </JSONPayload>
</RegularExpressionProtection>

NoPatternsToEnforce

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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

Пример сообщения об ошибке

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

Пример скриншота ошибки

Текст ошибки NoPatternsToEnforce

Причина

Если для какого-либо из элементов верхнего уровня ( <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <JSONPayload> ) не определен элемент <Pattern> в политике RegularExpressionProtection , то развертывание API-прокси завершится неудачей.

Диагноз

  1. Укажите название политики RegularExpressionProtection , в которой произошла ошибка, и дочерний элемент, у которого отсутствует элемент <Pattern> . Оба эти элемента можно найти в сообщении об ошибке.

    Например, в следующем сообщении об ошибке имя политики — Regular-Expression-Protection-1 , а дочерний элемент — XPath:

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. Проверьте политику защиты от регулярных выражений, которая не работает, и убедитесь, что дочерний элемент, определенный на шаге №1, не содержит элемент <Pattern> . Если элемент <Pattern> отсутствует в нем, то это и является причиной ошибки.

    Например, в следующей политике отсутствует элемент <Pattern> внутри <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>

    Поскольку элемент <XPath> не содержит элемента <Pattern> , развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что для любого из элементов <URIPath> , <QueryParam> , <Header> , <FormParam> , <XMLPayload> или <JSONPayload> указан хотя бы один <Pattern> . См. политику RegularExpressionProtection для получения информации о том, как правильно указать элемент.

Чтобы исправить приведенный выше пример, мы можем просто добавить элемент <Pattern> к элементу <XPath> под элементом <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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

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

Пример сообщения об ошибке

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

Пример скриншота ошибки

NONEmptyPrefixMappedToEmptyURI текст ошибки

Причина

Эта ошибка возникает, если политика RegularExpressionProtection имеет префикс, определенный в элементе <Namespace> внутри элемента <XMLPayload> , но URI не определен.

Диагноз

  1. Укажите политику RegularExpressionProtection , в которой произошла ошибка, и имя префикса, который не сопоставлен с URI. Оба эти элемента можно найти в сообщении об ошибке.

    Например, в следующем сообщении об ошибке имя политики — Regular Expression Protection-1, а префикс — apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.
  2. В XML-файле политики защиты от регулярных выражений, в котором произошел сбой, убедитесь, что имя префикса, заданного в элементе <Namespace> внутри элемента <XMLPayload> совпадает с именем префикса, указанным в сообщении об ошибке (шаг #1 выше).

    Например, следующая политика указывает префикс с именем apigee в элементе <Namespace> , который соответствует содержимому сообщения об ошибке:

    <?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. Проверьте, имеет ли элемент <Namespace> с указанным на шаге #2 префиксом действительный URI. Если URI отсутствует, это и является причиной ошибки.

    В приведенном выше примере политики защиты от регулярных выражений обратите внимание, что для элемента <Namespace> с префиксом apigee отсутствует URI; следовательно, вы получаете ошибку:

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

Разрешение

Убедитесь, что все элементы <Namespace> , определенные с префиксом, имеют соответствующий URI в политике извлечения переменных. Например:

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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Пример сообщения об ошибке

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

Пример скриншота ошибки

Текст ошибки DuplicatePrefix

Причина

Эта ошибка возникает, если политика RegularExpressionProtection имеет один и тот же префикс, определенный более одного раза в элементе <Namespace> внутри элемента <XMLPayload> .

Например, эта ошибка возникает из-за того, что префикс apigee определен дважды, как показано ниже:

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

Диагноз

  1. Укажите политику RegularExpressionProtection , в которой произошла ошибка, и имя префикса. Оба эти элемента можно найти в сообщении об ошибке.

    Например, в следующем сообщении об ошибке имя политики — Regular Expression Protection-1, а префикс — apigee:

    RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.
  2. В XML-файле политики защиты от регулярных выражений, в котором произошел сбой, убедитесь, что имя префикса, заданного в элементе <Namespace> внутри элемента <XMLPayload> совпадает с именем префикса, указанным в сообщении об ошибке (шаг #1 выше).

    Например, следующая политика указывает префикс с именем apigee в элементе <Namespace> , который соответствует содержимому сообщения об ошибке:

    <?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. Определите, был ли элемент <Namespace> с указанным на шаге #2 префиксом определен более одного раза. Если он определен более одного раза, то это и является причиной ошибки.

    В приведенном выше примере политики защиты от регулярных выражений обратите внимание, что элемент <Namespace> с префиксом apigee был определен дважды; поэтому возникает ошибка:

    Duplicate prefix apigee.

Разрешение

Убедитесь, что для каждого префикса в элементах <Namespace> политики RegularExpressionProtection существует только одно определение. Например:

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

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Пример сообщения об ошибке

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

Пример скриншота ошибки

Текст ошибки EmptyXPathExpression

Причина

Если в политике RegularExpressionProtection отсутствует элемент <Expression> внутри элемента <XPath> , то развертывание API-прокси завершится неудачей.

Диагноз

  1. Определите, какая политика защиты от регулярных выражений не сработала, из сообщения об ошибке. Например, в следующем сообщении об ошибке имя политики — Regular-Expression-Protection-1:

    RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.
  2. В XML-файле политики защиты от регулярных выражений, в котором произошла ошибка, определите, существует ли элемент <XMLPayload> с дочерним элементом <XPath> , в котором не определен элемент <Expression> , или же элемент <Expression> не имеет никакого значения. Если это так, то это и есть причина ошибки.

    Например, вот политика защиты от регулярных выражений, содержащая элемент <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>

    Поскольку внутри элемента <XPath> находится пустой элемент <Expression> , развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что политика RegularExpressionProtection содержит непустой и допустимый элемент <Expression> , определенный внутри элемента <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>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

EmptyJSONPathExpression

Сообщение об ошибке

Развертывание API-прокси через пользовательский интерфейс Edge или API управления Edge завершается с ошибкой, о которой сообщается ниже:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Пример сообщения об ошибке

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

Пример скриншота ошибки

Текст ошибки EmptyJSONPathExpression

Причина

Если в политике RegularExpressionProtection отсутствует элемент <Expression> внутри элемента <JSONPath> , то развертывание API-прокси завершится неудачей.

Диагноз

  1. Определите, какая политика защиты от регулярных выражений не сработала, из сообщения об ошибке. Например, в следующем сообщении об ошибке имя политики — Regular-Expression-Protection-1:

    Error Saving Revision 1
    RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.
  2. В XML-файле политики защиты от регулярных выражений, в котором произошла ошибка, определите, существует ли элемент <JSONPayload> с дочерним элементом <JSONPath> , в котором не определен элемент <Expression> , или же элемент <Expression> не имеет никакого значения. Если это так, то это и есть причина ошибки.

    Например, вот политика защиты от регулярных выражений, содержащая элемент <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>

    Поскольку внутри элемента <JSONPath> находится пустой элемент <Expression> , развертывание API-прокси завершается неудачей.

Разрешение

Убедитесь, что политика RegularExpressionProtection содержит непустой и допустимый элемент <Expression> , определенный внутри элемента <JSONPath> . Например:

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