500 내부 서버 오류 - BadPath

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서.
정보

증상

클라이언트 애플리케이션이 HTTP 상태 코드 500 Internal Server Error를 가져옵니다. API 호출에 대한 응답으로 오류 코드 protocol.http.BadPath

오류 메시지

클라이언트 애플리케이션은 다음과 같은 응답 코드를 받습니다.

HTTP/1.1 500 Internal Server Error

또한 다음과 같은 오류 메시지가 표시될 수 있습니다.

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

가능한 원인

이 오류는 백엔드 서버의 요청 URL이 흐름 변수로 표현되는 경우 발생합니다. target.url, 대신 물음표 (?)로 시작하는 path 를 포함합니다. (/)는 유효하지 않습니다.

사양에 따라 <ph type="x-smartling-placeholder"></ph> RFC 3986, 섹션 3: 구문 구성요소 및 <ph type="x-smartling-placeholder"></ph> RFC 3986, 섹션 3.3: 경로:

  1. URI 구문 에는 다음과 같은 구성요소가 있습니다.

            foo://example.com:8042/over/there?name=ferret#nose
            \_/   \______________/\_________/ \_________/ \__/
             |            |            |            |       |
          scheme      authority       path        query   fragment
    
  2. path 구성요소는 필수이며 및 항상 슬래시 (/)가 있습니다.

따라서 백엔드 서버의 요청 URL에 path 구성 요소가 있다면 슬래시 (/) 대신 물음표 (?)를 사용한 경우 Apigee Edge에서 500 Internal Server Error 및 오류 코드로 응답 protocol.http.BadPath입니다.

예를 들어 target.url에 값이 있는 경우 https://www.mocktarget.apigee.net?json로 설정된 경우 이 오류는 path는 물음표로 시작하므로 유효하지 않은 것으로 확인되었습니다. (?)을 슬래시 (/) 대신 사용합니다.

원인 설명 다음에 관한 문제 해결 안내
백엔드 서버 URL (target.url)의 경로가 잘못되었습니다. 흐름 변수로 표시되는 백엔드 서버 URL의 경로 구성요소 target.url이 앞으로가 아닌 물음표 (?)로 시작함 슬래시 (/). 에지 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

다음 도구/기술 중 하나를 사용하여 이 오류를 진단합니다.

API 모니터링

절차 #1: API 모니터링 사용

<ph type="x-smartling-placeholder">

API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.

  1. <ph type="x-smartling-placeholder"></ph> 다음 계정으로 Apigee Edge UI에 로그인: 역할을 수행하는 것이 좋습니다.
  2. 문제를 조사하려는 조직으로 전환합니다.

  3. 분석 > API 모니터링 > 조사 페이지를 엽니다.
  4. 오류가 관찰된 특정 기간을 선택합니다.
  5. 시간을 기준으로 결함 코드를 표시합니다.

    <ph type="x-smartling-placeholder">
  6. 다음과 같이 오류 코드가 protocol.http.BadPath인 셀을 선택하세요. 아래:

  7. 결함 코드 protocol.http.BadPath에 대한 정보는 다음과 같이 표시됩니다. 다음과 같습니다.

  8. 로그 보기 를 클릭하고 실패한 요청의 행을 펼칩니다.

  9. 로그 창에서 다음 세부정보를 확인합니다. <ph type="x-smartling-placeholder">
      </ph>
    • 상태 코드: 500
    • 오류 소스: target
    • 오류 코드: protocol.http.BadPath
  10. 결함 소스target이고 결함 코드가 다음과 같은 경우 protocol.http.BadPath이면 백엔드 서버 URL에 경로가 잘못되었습니다.

Trace

절차 #2: Trace 도구 사용

<ph type="x-smartling-placeholder">

Trace 도구를 사용하여 오류를 진단하는 방법은 다음과 같습니다.

  1. 추적 세션을 사용 설정하고 다음 중 하나를 수행합니다. <ph type="x-smartling-placeholder">
      </ph>
    • 500 Internal Server Error 오류가 발생할 때까지 기다립니다.
    • 문제를 재현할 수 있는 경우 API를 호출하여 문제를 재현합니다. 500 Internal Server Error
  2. 모든 FlowInfos 표시가 사용 설정되어 있는지 확인합니다.

  3. 실패한 요청 중 하나를 선택하고 trace를 검토합니다.
  4. 추적의 여러 단계를 살펴보고 오류가 발생한 위치를 찾습니다.
  5. 이 오류는 일반적으로 Target Request Flow Started(대상 요청 흐름 시작됨) 이후의 흐름에서 찾을 수 있습니다. 단계를 실행할 수 있습니다.

  6. 트레이스에서 오류 값을 확인합니다.

    오류: 요청 경로가 잘못됨

    대상 요청 흐름 시작됨 이후에 Apigee Edge에서 오류가 발생하므로 백엔드 서버 URL에 잘못된 경로가 있음을 나타냅니다. 이렇게 하면 URL을 나타내는 흐름 변수 target.url이 )가 Apigee Edge에서 잘못된 경로로 업데이트되었을 수 있습니다. 대상 요청 흐름의 정책 중 하나입니다

  7. 각 흐름의 역순으로 읽고 할당된 변수 섹션을 살펴봅니다. Target Request Flow Started(타겟 요청 흐름 시작됨) 단계로 진행합니다.
  8. 흐름 변수가 target.url 이었던 정책 확인 업데이트:

    JavaScript 정책에서 흐름 변수를 업데이트한 것을 보여주는 샘플 트레이스 target.url:

    위에 표시된 샘플 trace에서 흐름 변수 변수의 값을 확인합니다. target.url 는 다음과 같이 JS- SetTargetURL라는 JavaScript 정책에서 업데이트됩니다. target.url : https://mocktarget.apigee.net?json

  9. target.url의 값에는 다음과 같은 구성요소가 있습니다. <ph type="x-smartling-placeholder">
      </ph>
    • 스키마: https
    • 권한: mocktarget.apigee.net
    • 경로: ?json
  10. path 구성요소가 물음표 (?)로 시작하므로 슬래시 (/) 대신 Invalid request path입니다.
  11. 트레이스의 AX (애널리틱스 데이터 기록됨) 단계로 이동하여 클릭합니다.
  12. 아래로 스크롤하여 단계 세부정보 - 오류 헤더 섹션으로 이동한 후 X-Apigee-fault-codeX-Apigee-fault-source 값이 아래와 같이 표시됩니다.

  13. X-Apigee-fault-codeX-Apigee-fault-source의 값이 표시됩니다. protocol.http.BadPathtarget 로 각각 는 백엔드 서버 URL에 잘못된 경로가 있기 때문에 이 오류가 발생했음을 나타냅니다.

    응답 헤더
    X-Apigee-fault-code protocol.http.BadPath
    X-Apigee-fault-source target

NGINX

절차 #3: NGINX 액세스 로그 사용

<ph type="x-smartling-placeholder">

NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.

  1. Private Cloud 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP 500 Internal Server Error에 대한 주요 정보입니다.
  2. NGINX 액세스 로그를 확인합니다.

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    <ph type="x-smartling-placeholder">
  3. 오류 코드와 함께 500 오류가 있는지 검색하여 확인합니다. 특정 기간 동안 protocol.http.BadPath( 여전히 500로 실패하는 요청이 있는지 확인하세요.
  4. 일치하는 X-Apigee-fault-code 500 오류가 있는 경우 protocol.http.BadPath의 값을 구한 다음 X- Apigee 결함 소스

    NGINX 액세스 로그의 샘플 500 오류:

    NGINX 액세스 로그의 위 샘플 항목에는 X-Apigee- fault-codeX-Apigee-fault-source:

    헤더
    X-Apigee-fault-code protocol.http.BadPath
    X-Apigee-fault-source target

    X-Apigee-fault-codeX-Apigee-fault-source의 값은 다음과 같습니다. 각각 protocol.http.BadPathtarget 백엔드 서버 URL에 잘못된 경로가 있기 때문에 이 오류가 발생한 것입니다.

원인: 백엔드 서버 URL (target.url)에 잘못된 경로가 있습니다.

진단

  1. 다음에 설명된 대로 API 모니터링, Trace Tool 또는 NGINX 액세스 로그를 사용하여 500 Internal Server Error결함 코드오류 소스를 확인합니다. 일반적인 진단 단계.
  2. 오류 코드protocol.http.BadPath이고 오류 소스가 다음과 같은 경우 값이 target이면 백엔드 서버 URL에 잘못된 경로와 같은 '경로'를 통해 지정할 수 있습니다.
  3. 백엔드 서버 URL은 Apigee에서 흐름 변수 target.url로 표시됩니다. Edge. 이 오류는 일반적으로 백엔드 서버 URL을 업데이트하려고 할 때 발생합니다. (target.url) 동적으로 프록시/공유 흐름)가 있어서 잘못된 경로가 있는지 확인합니다.

    <ph type="x-smartling-placeholder">
  4. 흐름 변수 target.url에 실제로 유효하지 않은 변수가 있는지 확인 path 및 다음 방법 중 하나를 사용하여 해당 값의 소스를 가져올 수 있습니다.

    Trace

    Trace 도구 사용

    이 오류의 트레이스를 캡처한 경우 다음에 설명된 단계를 따르세요. Trace 도구 사용

    1. target.url에 잘못된 경로가 있는지(즉, 시작하는지) 확인 슬래시 (/) 대신 물음표 (?)를 사용하세요.
    2. 답이 '예'인 경우 target.url: 잘못된 경로를 포함합니다.

      JavaScript 정책에서 흐름 변수를 업데이트한 것을 보여주는 샘플 트레이스 target.url

    3. 위의 샘플 trace에서 JavaScript 정책이 잘못된 경로를 포함하도록 target.url 값을 수정하거나 업데이트했습니다.
    4. target.url에는 다음과 같은 구성요소가 있습니다. <ph type="x-smartling-placeholder">
        </ph>
      • 스키마: https
      • 권한: mocktarget.apigee.net
      • 경로: ?json

      경로가 앞으로가 아닌 물음표 (?)로 시작합니다. 슬래시 (/) 이므로 유효하지 않습니다.

    로그

    로그 서버에서 로그 사용

    1. 이 오류 (간헐적인 문제)에 대한 추적 정보가 없다면 흐름 변수의 값에 대한 정보를 target.url: <ph type="x-smartling-placeholder"></ph> MessageLogging 또는 <ph type="x-smartling-placeholder"></ph> Service콜아웃 정책을 업데이트합니다.
    2. 로그가 있는 경우 로그를 검토하고 <ph type="x-smartling-placeholder">
        </ph>
      1. target.url에 잘못된 경로가 있는지 확인합니다.
      2. 수정된 정책에 대한 정보를 확인할 수 있는지 확인합니다. target.url: 잘못된 경로를 포함합니다.

    API 프록시

    실패한 API 프록시 검토

    이 오류에 대한 추적이나 로그가 없는 경우 실패한 API를 검토하세요. 프록시에서 target.url 흐름 변수를 수정하거나 업데이트한 항목을 확인합니다. 잘못된 경로를 포함할 수 있습니다. 다음을 확인하세요.

    • API 프록시 내의 정책
    • 프록시에서 호출된 모든 공유 흐름
  5. 메시지를 수정하거나 흐름 변수 target.url를 업데이트하고 잘못된 경로를 갖도록 target.url를 업데이트합니다.

    다음은 흐름 변수 target.url을 업데이트하는 정책의 몇 가지 예시입니다. 이 오류를 일으키는 잘못된 경로를 포함할 수 있습니다.

    샘플 #1

    샘플 #1: target.url 변수를 업데이트하는 JavaScript 정책

    var url = "https://mocktarget.apigee.net?json"
    context.setVariable("target.url", url);
    

    위 샘플에서는 흐름 변수 target.url가 업데이트됩니다. 값이 https://mocktarget.apigee.net?json인 다른 속성에 포함된 변수 url.

    url의 값에는 다음과 같은 구성요소가 있습니다.

    • 스키마: https
    • 권한: mocktarget.apigee.net
    • 경로: ?json

    경로가 슬래시 대신 물음표 (?)로 시작합니다. (/)유효하지 않습니다. 따라서 Apigee Edge는 500 Internal Server Error(오류 코드: protocol.http.BadPath).

    샘플 #2

    샘플 #2: target.url 변수를 업데이트하는 JavaScript 정책 요청 헤더의 값에 따라

    var path = context.getVariable("request.header.Path");
    var url = "https://mocktarget.apigee.net" + path
    context.setVariable("target.url", url);
    

    위 샘플에서 흐름 변수 target.url가 업데이트된 것을 볼 수 있습니다. 에 포함된 값 https://mocktarget.apigee.net를 연결하여 변수 url 다른 변수 path의 값 request.header.Path.에서 값을 가져온 사용자

    실제 요청이나 trace에 액세스할 수 있으면 실제 값을 확인할 수 있습니다. request.header.Path에 전달되었습니다.

    사용자의 샘플 요청

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
    

    이 예에서 헤더 경로는 요청의 일부로 전송되지 않습니다. 따라서 JavaScript 정책의 path 변수는 null입니다.

    따라서 다음과 같은 전략을 구사하세요.

    • url = https://mocktarget.apigee.net + path
    • url = https://mocktarget.apigee.net + "?user"
    • target.url = https://mocktarget.apigee.net?user

    target.url의 값에는 다음과 같은 구성요소가 있습니다.

    • 스키마: https
    • 권한: mocktarget.apigee.net
    • 경로: ?user

    경로가 슬래시 대신 물음표 (?)로 시작합니다. (/)유효하지 않습니다. 따라서 Apigee Edge는 오류 코드 protocol.http.BadPath과 함께 500 Internal Server Error를 반환합니다.

    샘플 #3

    샘플 #3: AssignMessage 정책 업데이트 target.url 변수

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
        <DisplayName>AM-SetTargetURL</DisplayName>
        <AssignVariable>
             <Name>target.url</Name>
             <Value>https://mocktarget.apigee.net?echo</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>
    

    url의 값에는 다음과 같은 구성요소가 있습니다.

    • 스키마: https
    • 권한: mocktarget.apigee.net
    • 경로: ?echo

    다시 이 예에서 경로는 물음표 (?)로 시작합니다. 를 잘못된 슬래시 (/) 대신 사용합니다. 따라서 Apigee Edge가 오류 코드와 함께 500 Internal Server Error를 반환합니다. protocol.http.BadPath

해상도

URL 사양에 따름 <ph type="x-smartling-placeholder"></ph> RFC 3986, 섹션 3: 구문 구성요소: path 구성요소가 필수입니다. 항상 "/"로 시작해야 합니다(MUST). 따라서 이 문제를 해결하려면 다음 단계를 따르세요.

  1. 흐름 변수로 표시되는 백엔드 서버 URL이 target.url에는 항상 유효한 경로가 있으며 항상 슬래시 (/). <ph type="x-smartling-placeholder">
      </ph>
    1. 경우에 따라 경로에 리소스 이름이 없을 수도 있습니다. 그런 다음 경로에 적어도 슬래시 (/)가 있어야 합니다.
    2. 다른 변수를 사용하여 흐름 변수의 값을 결정하는 경우 target.url를 클릭한 다음 다른 변수에 잘못된 경로입니다.
    3. 흐름 변수의 값을 결정하기 위해 문자열 작업을 수행하는 경우 target.url를 반환한 다음 문자열의 결과 또는 결과가 연산의 유효하지 않은 경로가 없음을 알 수 있습니다.
  2. 위에서 설명한 샘플에서는 아래 설명에 따라 이 문제를 해결할 수 있습니다.

    샘플 #1

    샘플 #1: target.url 변수를 업데이트하는 JavaScript 정책

    다음에서 물음표 (?) 대신 슬래시 (/)를 변수 url를 사용하여 이 문제를 다음과 같이 수정합니다.

    var url = "https://mocktarget.apigee.net/json"
    context.setVariable("target.url", url);
    

    샘플 #2

    샘플 #2: target.url 변수를 업데이트하는 JavaScript 정책 요청 헤더의 값에 따라

    var path = context.getVariable("request.header.Path");
    var url = "https://mocktarget.apigee.net" + path
    context.setVariable("target.url", url);
    

    유효한 경로(예: /user)를 요청의 일부로 전달해야 합니다. 이 문제를 해결하려면 헤더 Path를 다음과 같이 설정하세요.

    샘플 요청:

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
    

    샘플 #3

    샘플 #3: AssignMessage 정책 업데이트 target.url 변수

    VerifyMessage 정책의 <Value> 요소에 유효한 경로를 추가합니다. 즉, 물음표 (?)를 a <Value> 요소의 슬래시 (/) 및 이 문제를 해결하려면 다음과 같이 https://mocktarget.apigee.net/echo로 설정하세요.

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
        <DisplayName>AM-SetTargetURL</DisplayName>
        <AssignVariable>
             <Name>target.url</Name>
             <Value>https://mocktarget.apigee.net/echo</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>
    

    사양

    Apigee Edge는 백엔드 서버 URL의 path 구성요소 가 다음에 따라 항상 슬래시(/)로 시작해야 합니다(MUST). 사양:

    사양
    <ph type="x-smartling-placeholder"></ph> RFC 3986, 섹션 3: 구문 구성요소
    <ph type="x-smartling-placeholder"></ph> RFC 3986, 섹션 3.3: 경로

    Apigee 지원팀의 도움이 더 필요한 경우 다음 수집하기 진단 정보를 제공합니다.

    진단 정보 수집 필요

    위의 안내를 따른 후에도 문제가 지속되면 다음을 수집합니다. Apigee Edge 지원팀에 문의하세요.

    퍼블릭 클라우드 사용자인 경우 다음 정보를 입력합니다.

    • 조직 이름
    • 환경 이름
    • API 프록시 이름
    • 오류 코드 protocol.http.BadPath을 사용하여 500 Internal Server Error를 재현하는 데 사용된 curl 명령어를 완료합니다.
    • API 요청에 대한 추적 파일

    Private Cloud 사용자인 경우 다음 정보를 입력합니다.

    • 실패한 요청에 대해 발견된 전체 오류 메시지
    • 환경 이름
    • API 프록시 번들
    • API 요청에 대한 추적 파일
    • NGINX 액세스 로그:

      /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

      위치: ORG, ENV, PORT#가 다음으로 대체됩니다. 실제값입니다.

    • 메시지 프로세서 시스템 로그 /opt/apigee/var/log/edge-message- processor/logs/system.log

    참조

    흐름 변수 - 대상