500 내부 서버 오류 - BadPath

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요.
info

증상

클라이언트 애플리케이션은 API 호출의 응답으로 오류 코드 protocol.http.BadPath와 함께 HTTP 상태 코드 500 Internal Server Error를 받습니다.

오류 메시지

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

HTTP/1.1 500 Internal Server Error

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

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

가능한 원인

이 오류는 흐름 변수 target.url로 표시된 백엔드 서버의 요청 URL에 슬래시 (/) 대신 물음표 (?)로 시작하는 path 가 포함된 경우에 발생하며, 이는 잘못된 것입니다.

사양 RFC 3986, 섹션 3: 문법 구성요소 및 RFC 3986, 섹션 3.3: 경로에 따라 다음을 충족해야 합니다.

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

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

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

예를 들어 target.url의 값이 https://www.mocktarget.apigee.net?json이면 path이 슬래시(/) 대신 물음표 (?)로 시작하므로 잘못된 것으로 간주되어 이 오류가 발생합니다.

원인 설명 다음에 관한 문제 해결 안내
백엔드 서버 URL (target.url)에 잘못된 경로가 있음 흐름 변수 target.url로 표시된 백엔드 서버 URL의 경로 구성요소가 슬래시 (/) 대신 물음표 (?)로 시작합니다. Edge Public 및 Private Cloud 사용자

일반적인 진단 단계

다음 도구/기법 중 하나를 사용하여 이 오류를 진단하세요.

API 모니터링

절차 1: API 모니터링 사용

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

  1. 적절한 역할이 있는 사용자로 Apigee Edge UI에 로그인합니다.
  2. 문제를 조사하려는 조직으로 전환합니다.

  3. 분석 > API 모니터링 > 조사 페이지로 이동합니다.
  4. 오류가 발생한 구체적인 기간을 선택합니다.
  5. 시간에 대한 오류 코드를 표시합니다.

  6. 아래와 같이 오류 코드 protocol.http.BadPath가 있는 셀을 선택합니다.

  7. 결함 코드 protocol.http.BadPath에 관한 정보가 아래와 같이 표시됩니다.

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

  9. 로그 창에서 다음 세부정보를 확인합니다.
    • 상태 코드: 500
    • 결함 소스: target
    • 오류 코드: protocol.http.BadPath
  10. 오류 소스가 target이고 오류 코드가 protocol.http.BadPath이면 백엔드 서버 URL에 잘못된 경로가 있음을 나타냅니다.

Trace

절차 2: Trace 도구 사용

Trace 도구를 사용하여 오류를 진단하려면 다음 단계를 따르세요.

  1. 추적 세션을 사용 설정하고 다음 중 하나를 사용합니다.
    • 500 Internal Server Error 오류가 발생할 때까지 기다리거나
    • 문제를 재현할 수 있는 경우 API를 호출하여 문제를 재현합니다. 500 Internal Server Error
  2. 모든 FlowInfo 표시가 사용 설정되어 있는지 확인합니다.

  3. 실패한 요청 중 하나를 선택하고 트레이스를 검사합니다.
  4. 트레이스의 여러 단계를 탐색하여 장애가 발생한 위치를 찾습니다.
  5. 일반적으로 아래와 같이 대상 요청 흐름 시작 단계 이후의 흐름에서 오류가 발생합니다.

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

    error: Invalid request path

    이 오류는 타겟 요청 흐름 시작됨 단계 후에 Apigee Edge에서 발생하므로 백엔드 서버 URL에 잘못된 경로가 있음을 나타냅니다. 이 문제는 Apigee Edge의 흐름 변수 target.url (백엔드 서버의 URL을 나타냄)가 타겟 요청 흐름의 정책 중 하나를 통해 잘못된 경로로 업데이트된 경우에 발생할 가능성이 가장 큽니다.

  7. 오류 흐름에서 타겟 요청 흐름 시작됨 단계까지 각 흐름을 역방향으로 검사하여 변수 읽기 및 할당됨 섹션을 확인합니다.
  8. 흐름 변수 target.url 가 업데이트된 정책을 확인합니다.

    자바스크립트 정책이 흐름 변수 target.url:을 업데이트했음을 보여주는 샘플 추적

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

  9. target.url의 값에는 다음 구성요소가 있습니다.
    • scheme: https
    • authority: mocktarget.apigee.net
    • path: ?json
  10. 경로 구성요소가 슬래시 (/) 대신 물음표 (?)로 시작하므로 Invalid request path 오류가 발생합니다.
  11. 트레이스에서 AX (분석 데이터 기록됨) 단계로 이동하여 클릭합니다.
  12. 단계 세부정보 - 오류 헤더 섹션까지 아래로 스크롤하여 아래와 같이 X-Apigee-fault-code 및 X-Apigee-fault-source 값을 확인합니다.

  13. X-Apigee-fault-code 및 X-Apigee-fault-source 값이 각각 protocol.http.BadPath 및 target 로 표시됩니다. 이는 백엔드 서버 URL에 잘못된 경로가 있어 이 오류가 발생했음을 나타냅니다.

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

NGINX

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

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

  1. 비공개 클라우드 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP 500 Internal Server Error에 관한 주요 정보를 확인할 수 있습니다.
  2. NGINX 액세스 로그를 확인합니다.

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

  3. 특정 기간 동안 (문제가 과거에 발생한 경우) 오류 코드 protocol.http.BadPath이 있는 500 오류가 있는지 또는 500로 인해 여전히 실패하는 요청이 있는지 검색합니다.
  4. X-Apigee-fault-code가 protocol.http.BadPath 값과 일치하는 500 오류가 발견되면 X-Apigee-fault-source 값을 확인합니다.

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

    위의 NGINX 액세스 로그 샘플 항목에는 X-Apigee-fault-code 및 X-Apigee-fault-source에 다음 값이 있습니다.

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

    X-Apigee-fault-code 및 X-Apigee-fault-source 값은 각각 protocol.http.BadPath 및 target 입니다. 이는 백엔드 서버 URL에 유효하지 않은 경로가 있어 이 오류가 발생했음을 나타냅니다.

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

진단

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

  4. 다음 방법 중 하나를 사용하여 흐름 변수 target.url에 실제로 잘못된 경로와 값의 소스가 있는지 확인합니다.

    Trace

    Trace 도구 사용

    이 오류의 트레이스를 캡처한 경우 Trace 도구 사용 및

    1. target.url에 잘못된 경로가 있는지, 즉 슬래시 (/) 대신 물음표 (?)로 시작하는지 확인합니다.
    2. 예인 경우 target.url 값이 잘못된 경로를 포함하도록 수정하거나 업데이트한 정책을 찾습니다.

      자바스크립트 정책이 흐름 변수 target.url 을 업데이트했음을 보여주는 샘플 추적

    3. 위 샘플 트레이스에서 JavaScript 정책이 잘못된 경로를 포함하도록 target.url 값을 수정하거나 업데이트한 것을 확인할 수 있습니다.
    4. target.url에는 다음과 같은 구성요소가 있습니다.
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?json

      경로가 슬래시 (/) 대신 물음표 (?)로 시작하므로, 유효하지 않습니다.

    로그

    로그 서버에서 로그 사용

    1. 이 오류 (간헐적 문제)에 대한 트레이스가 없는 경우 MessageLogging 또는 ServiceCallout 정책과 같은 정책을 사용하여 흐름 변수 target.url의 값에 관한 정보를 로그 서버에 로깅했는지 확인합니다.
    2. 로그가 있는 경우 로그를 검토하고
      1. target.url에 잘못된 경로가 있는지 확인합니다.
      2. target.url이 잘못된 경로를 포함하도록 수정한 정책에 관한 정보를 확인할 수 있는지 확인합니다.

    API 프록시

    실패한 API 프록시 검토

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

    • API 프록시 내 정책
    • 프록시에서 호출된 공유 흐름
  5. 흐름 변수 target.url를 수정하거나 업데이트하는 특정 정책 (예: AssignMessage 또는 JavaScript)을 주의 깊게 살펴보고 target.url가 잘못된 경로로 업데이트되는 원인을 확인합니다.

    다음은 이 오류를 유발하는 잘못된 경로를 포함하도록 흐름 변수 target.url를 업데이트하는 정책의 몇 가지 예입니다.

    샘플 1

    샘플 1: JavaScript 정책에서 target.url 변수 업데이트

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

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

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

    • scheme: https
    • authority: mocktarget.apigee.net
    • path: ?json

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

    샘플 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는 변수 url 에 포함된 값 https://mocktarget.apigee.net과 request.header.Path.에서 값을 가져온 다른 변수 path의 값을 연결하여 업데이트됩니다.

    실제 요청 또는 트레이스에 액세스할 수 있는 경우 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 값에는 다음 구성요소가 있습니다.

    • scheme: https
    • authority: mocktarget.apigee.net
    • path: ?user

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

    샘플 3

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

    <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 값에는 다음 구성요소가 있습니다.

    • scheme: https
    • authority: mocktarget.apigee.net
    • path: ?echo

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

해상도

URL 사양 RFC 3986, 섹션 3: 문법 구성요소에 따라 path 구성요소는 필수이며 항상 '/'로 시작해야 합니다. 아래 단계에 따라 이 문제를 해결하세요.

  1. 흐름 변수 target.url로 표시된 백엔드 서버 URL에 항상 유효한 경로가 있고 항상 슬래시 (/)로 시작하는지 확인합니다.
    1. 경로에 리소스 이름이 없는 경우 경로에 슬래시 (/)가 하나 이상 있는지 확인합니다.
    2. 다른 변수를 사용하여 흐름 변수 target.url의 값을 결정하는 경우 다른 변수에 잘못된 경로가 없는지 확인하세요.
    3. 문자열 작업을 실행하여 흐름 변수 target.url의 값을 결정하는 경우 문자열 작업의 결과 또는 결과에 잘못된 경로가 없는지 확인합니다.
  2. 위에서 설명한 샘플에서 다음과 같이 이 문제를 해결할 수 있습니다.

    샘플 1

    샘플 1: JavaScript 정책에서 target.url 변수 업데이트

    변수 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);

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

    샘플 요청:

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

    샘플 3

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

    AssignMessage 정책의 <Value> 요소에 유효한 경로를 추가합니다. 즉, <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).

    사양
    RFC 3986, 섹션 3: 문법 구성요소
    RFC 3986, 섹션 3.3: 경로

    Apigee 지원팀의 지원이 여전히 필요한 경우 진단 정보를 수집해야 함으로 이동하세요.

    진단 정보 수집 필요

    위 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 연락합니다.

    Public Cloud 사용자인 경우 다음 정보를 제공하세요.

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

    프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요.

    • 실패한 요청에 대해 확인된 전체 오류 메시지
    • 환경 이름
    • 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

    참조

    흐름 변수 - 타겟