정규 표현식 보호 정책 배포 오류 문제 해결

Apigee 및 Apigee Hybrid 문서입니다.
Apigee Edge 문서 보기

InvalidRegularExpression

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 오류 텍스트

원인

RegularExpressionProtection 정책의 <Pattern> 요소에 정규 표현식이 유효하지 않은 경우 API 프록시 배포가 실패합니다.

진단

  1. 오류 메시지에서 RegularExpressionProtection 정책의 이름을 식별합니다. 예를 들어 다음 오류에서 RegularExpressionProtection 정책 이름은 Regular-Expression-Protection-1:입니다.

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

  2. 실패한 정규 표현식 보호 정책 XML의 모든 <Pattern> 요소를 검사합니다. <Pattern> 요소에 잘못된 정규 표현식이 포함되어 있는지 확인합니다. <Pattern> 요소 중에 잘못된 정규 표현식이 포함된 경우 오류의 원인이 됩니다.

    예를 들어 다음 정책은 잘못된 정규 표현식으로 간주되는 foo){2}의 Pattern> 값을 지정합니다. 

    <?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 프록시 배포는 실패합니다.

해결 방법

RegularExpressionProtection 정책의 각 <Pattern> 요소에 유효한 정규 표현식이 포함되어 있는지 확인합니다. 정규 표현식을 디버깅하기 위해 다양한 온라인 또는 오프라인 정규식 도구를 검색할 수 있습니다. 위에 표시된 정규 표현식 보호 정책의 예시를 수정하려면 누락된 괄호를 추가하세요.

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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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에서 Expression 요소에 설정된 XPath가 위 1단계의 오류 메시지에서 식별된 XPath와 일치하는지 확인합니다.

    예를 들어 다음 정책에서는 오류 메시지의 내용과 일치하는 /notapigee:foo/notapigee:bar로 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>/notapigee:foo/notapigee:bar</Expression>
             <Type>nodeset</Type>
             <Pattern>pattern</Pattern>
             <Pattern>pattern2</Pattern>
         </XPath>
     </XMLPayload>
</RegularExpressionProtection>
  3. RegularExpressionProtection 정책에서 <Namespaces> 및 <Expression> 요소를 검사합니다. 오류 메시지에 표시된 특정 <Expression>이 RegularExpressionProtection 정책에 선언된 네임스페이스의 일부가 아닌 프리픽스 또는 값을 사용하는 경우 오류의 원인이 됩니다.

    특정 RegularExpressionProtection 정책 예시에서 <XPath>가 프리픽스 notapigee를 사용하는 것을 볼 수 있습니다.

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

    하지만 프리픽스 notapigee는 <Namespace> 요소에 정의되지 않았으므로 <XPath>의 컴파일이 실패하면서 배포 실패가 발생합니다.

해결 방법

<XPath> 요소에서 <Expression> 요소에 사용 중인 모든 네임스페이스가 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>

CannotBeConvertedToNodeset

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 오류 텍스트

원인

정규 표현식 정책에 <Type> 유형이 nodeset로 정의된 <XPath> 표현식이 있지만 표현식을 nodeset로 변환할 수 없으면 API 프록시 배포가 실패합니다.

진단

  1. 오류가 발생한 RegularExpressionProtection 정책과 nodeset으로 변환할 수 없는 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가 위 1단계의 오류 메시지에서 식별된 XPath와 일치하는지 확인합니다.

    예를 들어 다음 정책에서는 오류 메시지의 내용과 일치하는 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. <XPath> 요소 아래의 <Type> 요소에서 설정된 값을 검사합니다. <Type> 요소가 nodeset이면 오류가 발생합니다.

    이 예시에서 XPath 표현식은 1개 이상의 노드를 반환하지 않는 count()입니다. API 프록시 배포는 실패합니다.

해결 방법

<Type> 요소가 nodeset로 설정된 경우 <XPath>에 설정된 <Expression> 요소 결과가 하나 이상의 노드인지 확인합니다. 또는 사용 사례에 따라 <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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 오류 텍스트

원인

정규 표현식 보호 정책의 <JSONPath> 요소 아래에서 <Expression> 요소가 잘못된 JSONPath 표현식으로 설정된 경우 API 프록시 배포가 실패합니다.

진단

  1. 오류가 발생하고 잘못된 JSONPath 표현식이 사용된 RegularExpressionProtection 정책의 이름을 확인합니다. 오류 메시지에서 이러한 항목을 모두 확인할 수 있습니다.

    예를 들어 다음 오류에서 정책 이름은 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에서 Expression 요소에 설정된 JSONPath가 위 1단계의 오류 메시지에서 식별된 JSONPath와 일치하는지 확인합니다.

    예를 들어 다음 정책은 <JSONPath> 요소 아래에 Expression 요소를 오류 메시지의 내용과 일치하는 $.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. 정책의 <JSONPath> 요소 아래에서 <Expression> 요소를 검사합니다. JSONPath 구문과 일치하지 않은 경우 이는 오류의 원인이 됩니다. 위의 예시에서는 닫는 대괄호가 누락되어 표현식이 무효화됩니다.

    JSON Path 표현식이 유효하지 않으므로 API 프록시 배포가 실패합니다.

해결 방법

정규 표현식 보호 정책의 <JSONPath> 요소 내부에 있는 <Expression> 요소의 값이 유효한 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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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>)에 RegularExpressionProtection 정책에 정의된 <Pattern> 요소가 없으면 API 프록시 배포가 실패합니다.

진단

  1. 오류가 발생한 RegularExpressionProtection 정책의 이름과 <Pattern> 요소가 없는 하위 요소의 이름을 확인합니다. 오류 메시지에서 이러한 항목을 모두 확인할 수 있습니다.

    예를 들어 다음 오류에서 정책 이름은 Regular-Expression-Protection-1이고 하위 요소는 XPath:입니다.

    RegularExpressionProtection Regular-Expression-Protection-1: No patterns to enforce in XPath.
  2. 실패한 정규 표현식 보호 정책을 검토하고 1단계에서 식별된 하위 요소에 <Pattern> 요소가 없는지 확인합니다. <Pattern> 요소가 없으면 오류의 원인이 됩니다.

    예를 들어 다음 정책의 <XPath>에는 <Pattern> 요소가 없습니다.

    <?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 정책을 참조하세요.

위의 예시를 수정하려면 <XMLPayload> 아래의 <XPath> 요소에 <Pattern> 요소를 추가하면 됩니다.

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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 정책에 <XMLPayload> 요소 아래의 <Namespace> 요소에서 정의된 프리픽스가 있지만 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의 <XMLPayload> 요소 아래 <Namespace> 요소에 설정된 프리픽스 이름이 위 1단계의 오류 메시지에서 식별된 프리픽스 이름과 일치하는지 확인합니다.

    예를 들어 다음 정책은 <Namespace> 요소의 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"/>
          <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. 2단계에서 식별된 특정 프리픽스가 있는 <Namespace> 요소에 유효한 URI가 있는지 확인합니다. URI가 누락되었다면 이는 오류의 원인이 됩니다.

    위에 표시된 정규 표현식 보호 정책 예시에서는 프리픽스 apigee가 있는 <Namespace> 요소에 해당하는 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

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 정책에 <XMLPayload> 요소 아래의 <Namespace> 요소에서 두 번 이상 정의된 프리픽스와 동일한 프리픽스가 있으면 발생합니다.

예를 들어 이 오류는 아래와 같이 프리픽스 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의 <XMLPayload> 요소 아래 <Namespace> 요소에 설정된 프리픽스 이름이 위 1단계의 오류 메시지에서 식별된 프리픽스 이름과 일치하는지 확인합니다.

    예를 들어 다음 정책은 <Namespace> 요소의 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>
          <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. 2단계에서 식별된 특정 프리픽스가 있는 <Namespace> 요소가 두 번 이상 정의되었는지 확인합니다. 두 번 이상 정의되었으면 이는 오류의 원인입니다.

    위에 표시된 정규 표현식 보호 정책 예시에서는 프리픽스 apigee가 있는 <Namespace> 요소가 두 번 정의되었으므로 다음과 같은 오류가 발생합니다.

    Duplicate prefix apigee.

해결 방법

RegularExpressionProtection 정책에 있는 <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>
        </Namespaces>
        <XPath>
          <Expression>/apigee:Greeting/apigee:User</Expression>
          <Type>string</Type>
          <Pattern>REGEX PATTERN</Pattern>
        </XPath>
      </XMLPayload>
    </RegularExpressionProtection>

EmptyXPathExpression

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 정책에 <XPath> 요소 내에 설정된 <Expression> 요소가 없으면 API 프록시 배포가 실패합니다.

진단

  1. 오류 메시지에서 실패한 정규 표현식 보호 정책을 식별합니다. 예를 들어 다음 오류에서 정책 이름은 Regular-Expression-Protection-1입니다.

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

  2. 실패한 정규 표현식 보호 정책 XML에 정의된 <Expression> 요소가 없는 <XPath> 하위 요소가 있는 <XMLPayload> 요소가 있는지 또는 <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정책에 <XPath> 요소 아래에 비어 있지 않은 유효한 <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:Greeting/apigee:User</Expression>
      <Type>string</Type>
      <Pattern>REGEX PATTERN</Pattern>
    </XPath>
  </XMLPayload>
</RegularExpressionProtection>

EmptyJSONPathExpression

오류 메시지

다음 오류 메시지와 함께 Apigee UI 또는 API를 통한 API 프록시의 배포가 실패합니다.

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 정책에 <JSONPath> 요소 내에 설정된 <Expression> 요소가 없으면 API 프록시 배포가 실패합니다.

진단

  1. 오류 메시지에서 실패한 정규 표현식 보호 정책을 식별합니다. 예를 들어 다음 오류에서 정책 이름은 Regular-Expression-Protection-1입니다.

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

  2. 실패한 정규 표현식 보호 정책 XML에 정의된 <Expression> 요소가 없는 <JSONPath> 하위 요소가 있는 <JSONPayload> 요소가 있는지 또는 <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정책에 <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>