Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Rozwiązywanie problemów z wdrażaniem zasady ochrony wyrażeń regularnych

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

InvalidRegularExpression

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu InvalidRegularExpression

Przyczyna

Jeśli wyrażenie regularne w elemencie <Pattern> zasady RegularExpressionProtection jest nieprawidłowe, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

Z komunikatu o błędzie odczytaj nazwę zasady RegularExpressionProtection. Na przykład w tym błędzie nazwa zasad RegularExpressionProtection to 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.

Sprawdź wszystkie elementy <Pattern> w pliku XML zasad ochrony wyrażeń regularnych, które nie zostały zastosowane. Sprawdź, czy któryś z elementów <Pattern> zawiera nieprawidłowe wyrażenie regularne. Jeśli któryś z elementów <Pattern> zawiera nieprawidłowe wyrażenie regularne, to jest to przyczyną błędu.

Na przykład ta zasada określa wartość Pattern> w polu foo){2}, co jest uznawane za nieprawidłowe wyrażenie regularne:
```
<?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>
```
W powyższym przykładzie w wyrażeniu regularnym podanym w <Pattern> brakuje nawiasu otwierającego. Dlatego jest ono uznawane za nieprawidłowe wyrażenie regularne. Wdrożenie proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że każdy element <Pattern> w zasadach RegularExpressionProtection zawiera prawidłowe wyrażenie regularne. Możesz wyszukać różne narzędzia online lub offline do wyrażeń regularnych, aby debugować wyrażenia regularne. Aby poprawić przykładowe zasady ochrony wyrażeń regularnych pokazane powyżej, dodaj brakujące nawiasy:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu XPathCompilationFailed

Przyczyna

Jeśli prefiks lub wartość użyta w elemencie <XPath> nie należy do żadnej z zadeklarowanych przestrzeni nazw w zasadzie RegularExpressionProtection, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Więcej informacji o przestrzeniach nazw, XPath i prefiksach znajdziesz w artykule XML Namespaces and How They Affect XPath and XSLT (Przestrzenie nazw XML i ich wpływ na XPath i XSLT).

Diagnostyka

Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd, oraz użyte wyrażenie XPath. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie XPath to /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.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy ścieżka XPath ustawiona w elemencie Expression jest zgodna ze ścieżką XPath podaną w komunikacie o błędzie (krok 1 powyżej).

Na przykład te zasady określają ścieżkę XPath jako /notapigee:foo/notapigee:bar, która pasuje do tego, co znajduje się w komunikacie o błędzie:

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

Sprawdź elementy <Namespaces> i <Expression> w zasadach RegularExpressionProtection. Jeśli konkretny element <Expression> wskazany w komunikacie o błędzie używa prefiksu lub wartości, które nie są częścią przestrzeni nazw zadeklarowanych w zasadach RegularExpressionProtection, to jest to przyczyną błędu.
Zwróć uwagę, że w przykładzie zasad RegularExpressionProtection konkretny element <XPath> używa prefiksu notapigee:
```
<Expression>/notapigee:foo/notapigee:bar</Expression>
```
Prefiks notapigee nie jest jednak zdefiniowany w żadnym z elementów <Namespace>, dlatego kompilacja <XPath> kończy się niepowodzeniem, co prowadzi do niepowodzenia wdrożenia.

Rozdzielczość

Upewnij się, że wszystkie przestrzenie nazw używane w elementach <Expression> w elementach <XPath> są zadeklarowane w zasadach RegularExpressionProtection. Aby poprawić powyższy przykład, możesz zastąpić prefiks notapigee prefiksem apigee, który jest zadeklarowany w przestrzeniach nazw:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu CannotBeConvertedToNodeset

Przyczyna

Jeśli zasada wyrażeń regularnych zawiera wyrażenie <XPath>, w którym element <Type> jest zdefiniowany jako nodeset, ale wyrażenia nie można przekonwertować na nodeset, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

Określ zasadę RegularExpressionProtection, w której wystąpił błąd, oraz wyrażenie XPath, którego nie można przekonwertować na zbiór węzłów. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie XPath to 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.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy ścieżka XPath ustawiona w elemencie <Expression> elementu <XPath> jest zgodna ze ścieżką XPath podaną w komunikacie o błędzie (krok 1 powyżej).

Na przykład te zasady określają wartość count(//apigee:foo), która odpowiada wartości w komunikacie o błędzie:

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

Sprawdź wartość ustawioną w elemencie <Type> pod elementem <XPath>. Jeśli element <Type> ma wartość nodeset, to jest to przyczyna błędu.

W tym przykładzie wyrażenie XPath to count(), które nie zwraca co najmniej 1 węzła. Wdrożenie proxy interfejsu API nie powiedzie się.

Rozdzielczość

Jeśli element <Type> jest ustawiony na nodeset, upewnij się, że wynikiem elementu <Expression> ustawionego w <XPath> jest co najmniej 1 węzeł. Możesz też zmienić element <Type> na bardziej odpowiednią wartość w zależności od przypadku użycia.

Aby naprawić powyższy przykład, możesz zmienić element <Expression> na inną wartość, która może zwracać węzły:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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.

Przykładowy komunikat o błędzie

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.

Przykładowy zrzut ekranu z błędem

Tekst błędu JSONPathCompilationFailed

Przyczyna

Jeśli element <Expression> w elemencie <JSONPath> zasady ochrony wyrażeń regularnych jest ustawiony na nieprawidłowe wyrażenie JSONPath, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd i użyto nieprawidłowego wyrażenia JSONPath. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1, a wyrażenie JSONPath to $.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.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy ścieżka JSONPath ustawiona w elemencie Expression jest zgodna ze ścieżką JSONPath podaną w komunikacie o błędzie (krok 1 powyżej).

Na przykład te zasady określają element Expression w elemencie <JSONPath> jako $.store.book[*.author, co odpowiada treści komunikatu o błędzie:

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

Sprawdź element <Expression> w ramach elementu <JSONPath> w zasadach. Jeśli nie pasuje do składni JSONPath, to jest przyczyną błędu. W powyższym przykładzie brakuje zamykającego nawiasu kwadratowego, co sprawia, że wyrażenie jest nieprawidłowe.

Wyrażenie ścieżki JSON jest nieprawidłowe, więc wdrożenie proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że wartość elementu <Expression> w elemencie <JSONPath> w zasadzie ochrony wyrażeń regularnych jest prawidłowym wyrażeniem JSONPath.

Aby poprawić przykład pokazany powyżej, możesz dodać brakujący prawy nawias kwadratowy do wartości elementu <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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NothingToEnforce

Przyczyna

Jeśli zasady RegularExpressionProtection nie zawierają żadnego z elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Jak wskazano w komunikacie o błędzie, zasady RegularExpressionProtection muszą zawierać co najmniej jeden z tych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>.

Diagnostyka

Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd. Znajdziesz go w komunikacie o błędzie. Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1:
```
RegularExpressionProtection Regular-Expression-Protection-1: at least one of URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload is mandatory.
```
Sprawdź zasadę ochrony wyrażeń regularnych, która nie została zastosowana (zidentyfikowaną w kroku 1 powyżej). Jeśli zasady nie zawierają co najmniej jednego z tych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>, to jest to przyczyną błędu.

Na przykład ta zasada ochrony wyrażeń regularnych nie zawiera żadnego z wymienionych powyżej elementów:
```
<?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>
```
Ponieważ w zasadach Extract Variables nie ma żadnych elementów obowiązkowych, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection zawiera co najmniej jeden z tych obowiązkowych elementów: <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>. Na przykład:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NoPatternsToEnforce

Przyczyna

Jeśli którykolwiek z elementów najwyższego poziomu (<URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload>) nie ma elementu <Pattern> zdefiniowanego w zasadach RegularExpressionProtection, wdrożenie proxy interfejsu API nie powiedzie się.

Diagnostyka

Określ nazwę zasady RegularExpressionProtection, w której wystąpił błąd, oraz element podrzędny, który nie ma elementu <Pattern>. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1, a element podrzędny to XPath:.
```
RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
```

Sprawdź zasadę ochrony wyrażeń regularnych, która nie działa, i upewnij się, że element podrzędny zidentyfikowany w kroku 1 nie zawiera elementu <Pattern>. Jeśli element <Pattern> nie istnieje, to jest to przyczyną błędu.

Na przykład w tych zasadach element <Pattern> nie znajduje się w elemencie <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>

Ponieważ element <XPath> nie zawiera elementu <Pattern>, wdrożenie proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że co najmniej jeden z elementów <URIPath>, <QueryParam>, <Header>, <FormParam>, <XMLPayload> lub <JSONPayload> ma określony co najmniej jeden element <Pattern>. Informacje o tym, jak prawidłowo określić element, znajdziesz w zasadach dotyczących ochrony wyrażeń regularnych.

Aby poprawić powyższy przykład, wystarczy dodać element <Pattern> do elementu <XPath> pod elementem <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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

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

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu NONEmptyPrefixMappedToEmptyURI

Przyczyna

Ten błąd występuje, jeśli zasada RegularExpressionProtection ma prefiks zdefiniowany w elemencie <Namespace> w elemencie <XMLPayload>, ale nie ma zdefiniowanego adresu URI.

Diagnostyka

Określ zasadę RegularExpressionProtection, w której wystąpił błąd, oraz nazwę prefiksu, który nie jest mapowany na identyfikator URI. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular Expression Protection-1, a prefiks to apigee:
```
RegularExpressionProtection Regular-Expression-Protection-1: Non-empty prefix apigee cannot be mapped to empty uri.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy nazwa prefiksu ustawiona w elemencie <Namespace> w elemencie <XMLPayload> jest zgodna z nazwą prefiksu podaną w komunikacie o błędzie (krok 1 powyżej).

Na przykład te zasady określają prefiks o nazwie apigee w elemencie <Namespace>, który pasuje do tego , co znajduje się w komunikacie o błędzie:

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

Sprawdź, czy element <Namespace> z określonym prefiksem zidentyfikowanym w kroku 2 ma prawidłowy identyfikator URI. Jeśli identyfikator URI nie jest podany, to jest przyczyną błędu.

W przykładzie zasady ochrony wyrażeń regularnych powyżej zwróć uwagę, że nie ma identyfikatora URI odpowiadającego elementowi <Namespace> z prefiksem apigee. Dlatego pojawia się błąd:
```
Non-empty prefix apigee cannot be mapped to empty uri.
```

Rozdzielczość

Sprawdź, czy wszystkie elementy <Namespace> zdefiniowane z prefiksem mają odpowiedni identyfikator URI w zasadach wyodrębniania zmiennych. Na przykład:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Duplicate prefix prefix_name.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu DuplicatePrefix

Przyczyna

Ten błąd występuje, jeśli zasada RegularExpressionProtection ma ten sam prefiks zdefiniowany więcej niż raz w elemencie <Namespace> w elemencie <XMLPayload>.

Ten błąd występuje na przykład dlatego, że prefiks apigee jest zdefiniowany 2 razy, jak pokazano poniżej:

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

Diagnostyka

Określ zasady RegularExpressionProtection, w których wystąpił błąd, oraz nazwę prefiksu. Oba te elementy znajdziesz w komunikacie o błędzie.

Na przykład w tym błędzie nazwa zasady to Regular Expression Protection-1, a prefiks to apigee:
```
RegularExpressionProtection Regular-Expression-Protection-1: Duplicate prefix apigee.
```

Na przykład te zasady określają prefiks o nazwie apigee w elemencie <Namespace>, który pasuje do tego , co znajduje się w komunikacie o błędzie:

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

Sprawdź, czy element <Namespace> z określonym prefiksem zidentyfikowanym w kroku 2 został zdefiniowany więcej niż raz. Jeśli jest zdefiniowana więcej niż raz, to jest to przyczyną błędu.

W przykładzie zasady ochrony wyrażeń regularnych powyżej element <Namespace> z prefiksem apigee został zdefiniowany 2 razy, dlatego pojawia się błąd:
```
Duplicate prefix apigee.
```

Rozdzielczość

Upewnij się, że w elementach <Namespace> w zasadach RegularExpressionProtection jest tylko jedna definicja każdego prefiksu. Na przykład:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty XPath expression.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu EmptyXPathExpression

Przyczyna

Jeśli w zasadzie RegularExpressionProtection w elemencie <XPath> nie ma ustawionego elementu <Expression>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

Zidentyfikuj zasadę ochrony wyrażeń regularnych, której nie udało się zastosować, na podstawie komunikatu o błędzie. Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1:
```
RegularExpressionProtection Regular-Expression-Protection-1: Empty XPath expression.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy występuje element <XMLPayload> z elementem podrzędnym <XPath>, w którym nie zdefiniowano elementu <Expression>, lub czy element <Expression> nie ma ustawionej żadnej wartości. Jeśli tak, to jest to przyczyna błędu.

Oto przykład zasady ochrony wyrażeń regularnych, która zawiera element <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>

Ponieważ w elemencie <XPath> znajduje się pusty element <Expression>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection ma niepusty i prawidłowy element <Expression> zdefiniowany w elemencie <XPath>. Na przykład:

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

Komunikat o błędzie

Wdrażanie serwera proxy interfejsu API za pomocą interfejsu Edge UI lub interfejsu Edge Management API kończy się niepowodzeniem i wyświetla ten komunikat o błędzie:

Error Saving Revision revision_number
RegularExpressionProtection policy_name: Empty JSONPath expression.

Przykładowy komunikat o błędzie

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

Przykładowy zrzut ekranu z błędem

Tekst błędu EmptyJSONPathExpression

Przyczyna

Jeśli w zasadzie RegularExpressionProtection w elemencie <JSONPath> nie ma ustawionego elementu <Expression>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Diagnostyka

Zidentyfikuj zasadę ochrony wyrażeń regularnych, której nie udało się zastosować, na podstawie komunikatu o błędzie. Na przykład w tym błędzie nazwa zasady to Regular-Expression-Protection-1:
```
Error Saving Revision 1
RegularExpressionProtection Regular-Expression-Protection-1: Empty JSONPath expression.
```

W pliku XML nieudanej zasady ochrony wyrażeń regularnych sprawdź, czy występuje element <JSONPayload> z elementem podrzędnym <JSONPath>, w którym nie zdefiniowano elementu <Expression>, lub czy element <Expression> nie ma ustawionej żadnej wartości. Jeśli tak, to jest to przyczyna błędu.

Oto przykład zasady ochrony wyrażeń regularnych, która zawiera element <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>

Ponieważ w elemencie <JSONPath> znajduje się pusty element <Expression>, wdrożenie serwera proxy interfejsu API nie powiedzie się.

Rozdzielczość

Upewnij się, że zasada RegularExpressionProtection ma niepusty i prawidłowy element <Expression> zdefiniowany w elemencie <JSONPath>. Na przykład:

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