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: 경로에 따라 다음을 충족해야 합니다.
URI 구문 에는 다음과 같은 구성요소가 있습니다.
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragmentpath구성요소는 필수이며 슬래시(/)로 시작하고 항상 슬래시가 있어야 합니다(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 모니터링을 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- 적절한 역할이 있는 사용자로 Apigee Edge UI에 로그인합니다.
문제를 조사하려는 조직으로 전환합니다.
- 분석 > API 모니터링 > 조사 페이지로 이동합니다.
- 오류가 발생한 구체적인 기간을 선택합니다.
시간에 대한 오류 코드를 표시합니다.
아래와 같이 오류 코드
protocol.http.BadPath가 있는 셀을 선택합니다.
결함 코드
protocol.http.BadPath에 관한 정보가 아래와 같이 표시됩니다.
로그 보기 를 클릭하고 실패한 요청의 행을 펼칩니다.
- 로그 창에서 다음 세부정보를 확인합니다.
- 상태 코드:
500 - 결함 소스:
target - 오류 코드:
protocol.http.BadPath
- 상태 코드:
- 오류 소스가
target이고 오류 코드가protocol.http.BadPath이면 백엔드 서버 URL에 잘못된 경로가 있음을 나타냅니다.
Trace
절차 2: Trace 도구 사용
Trace 도구를 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- 추적 세션을 사용 설정하고 다음 중 하나를 사용합니다.
500 Internal Server Error오류가 발생할 때까지 기다리거나- 문제를 재현할 수 있는 경우 API를 호출하여 문제를 재현합니다.
500 Internal Server Error
모든 FlowInfo 표시가 사용 설정되어 있는지 확인합니다.

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

트레이스에서 오류 값을 확인합니다.
error: Invalid request path
이 오류는 타겟 요청 흐름 시작됨 단계 후에 Apigee Edge에서 발생하므로 백엔드 서버 URL에 잘못된 경로가 있음을 나타냅니다. 이 문제는 Apigee Edge의 흐름 변수
target.url(백엔드 서버의 URL을 나타냄)가 타겟 요청 흐름의 정책 중 하나를 통해 잘못된 경로로 업데이트된 경우에 발생할 가능성이 가장 큽니다.- 오류 흐름에서 타겟 요청 흐름 시작됨 단계까지 각 흐름을 역방향으로 검사하여 변수 읽기 및 할당됨 섹션을 확인합니다.
- 흐름 변수
target.url가 업데이트된 정책을 확인합니다.자바스크립트 정책이 흐름 변수
target.url:을 업데이트했음을 보여주는 샘플 추적
위의 샘플 추적에서
JS- SetTargetURL이라는 JavaScript 정책에서 흐름 변수target.url의 값이 다음과 같이 업데이트됩니다.target.url : https://mocktarget.apigee.net?json target.url의 값에는 다음 구성요소가 있습니다.- scheme:
https - authority:
mocktarget.apigee.net - path:
?json
- scheme:
- 경로 구성요소가 슬래시 (
/) 대신 물음표 (?)로 시작하므로Invalid request path오류가 발생합니다. - 트레이스에서 AX (분석 데이터 기록됨) 단계로 이동하여 클릭합니다.
단계 세부정보 - 오류 헤더 섹션까지 아래로 스크롤하여 아래와 같이 X-Apigee-fault-code 및 X-Apigee-fault-source 값을 확인합니다.

X-Apigee-fault-code 및 X-Apigee-fault-source 값이 각각
protocol.http.BadPath및target로 표시됩니다. 이는 백엔드 서버 URL에 잘못된 경로가 있어 이 오류가 발생했음을 나타냅니다.응답 헤더 값 X-Apigee-fault-code protocol.http.BadPathX-Apigee-fault-source target
NGINX
절차 3: NGINX 액세스 로그 사용
NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 단계를 따르세요.
- 비공개 클라우드 사용자인 경우 NGINX 액세스 로그를 사용하여 HTTP
500 Internal Server Error에 관한 주요 정보를 확인할 수 있습니다. NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- 특정 기간 동안 (문제가 과거에 발생한 경우) 오류 코드
protocol.http.BadPath이 있는500오류가 있는지 또는500로 인해 여전히 실패하는 요청이 있는지 검색합니다. 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.BadPathX-Apigee-fault-source targetX-Apigee-fault-code 및 X-Apigee-fault-source 값은 각각
protocol.http.BadPath및target입니다. 이는 백엔드 서버 URL에 유효하지 않은 경로가 있어 이 오류가 발생했음을 나타냅니다.
원인: 백엔드 서버 URL (target.url)에 잘못된 경로가 있음
진단
- 일반적인 진단 단계에 설명된 대로 API 모니터링, 추적 도구 또는 NGINX 액세스 로그를 사용하여
500 Internal Server Error의 오류 코드와 오류 소스를 확인합니다. - 오류 코드가
protocol.http.BadPath이고 오류 소스의 값이target이면 백엔드 서버 URL에 잘못된 경로가 있는 것입니다. 백엔드 서버 URL은 Apigee Edge에서 흐름 변수
target.url로 표시됩니다. 이 오류는 일반적으로 대상 요청 흐름에서 정책(프록시/공유 흐름 내)을 사용하여 백엔드 서버 URL (target.url)을 동적으로 업데이트하려고 할 때 잘못된 경로가 있는 경우에 발생합니다.다음 방법 중 하나를 사용하여 흐름 변수
target.url에 실제로 잘못된 경로와 값의 소스가 있는지 확인합니다.Trace
Trace 도구 사용
이 오류의 트레이스를 캡처한 경우 Trace 도구 사용 및
target.url에 잘못된 경로가 있는지, 즉 슬래시 (/) 대신 물음표 (?)로 시작하는지 확인합니다.예인 경우
target.url값이 잘못된 경로를 포함하도록 수정하거나 업데이트한 정책을 찾습니다.자바스크립트 정책이 흐름 변수
target.url을 업데이트했음을 보여주는 샘플 추적
- 위 샘플 트레이스에서 JavaScript 정책이 잘못된 경로를 포함하도록
target.url값을 수정하거나 업데이트한 것을 확인할 수 있습니다. target.url에는 다음과 같은 구성요소가 있습니다.- scheme:
https - authority:
mocktarget.apigee.net - path:
?json
경로가 슬래시 (
/) 대신 물음표 (?)로 시작하므로, 유효하지 않습니다.- scheme:
로그
로그 서버에서 로그 사용
- 이 오류 (간헐적 문제)에 대한 트레이스가 없는 경우
MessageLogging 또는
ServiceCallout 정책과 같은 정책을 사용하여 흐름 변수
target.url의 값에 관한 정보를 로그 서버에 로깅했는지 확인합니다. - 로그가 있는 경우 로그를 검토하고
target.url에 잘못된 경로가 있는지 확인합니다.target.url이 잘못된 경로를 포함하도록 수정한 정책에 관한 정보를 확인할 수 있는지 확인합니다.
API 프록시
실패한 API 프록시 검토
이 오류에 대한 트레이스나 로그가 없는 경우 실패한 API 프록시를 검토하여 흐름 변수
target.url를 수정하거나 업데이트하여 잘못된 경로를 포함한 항목을 확인합니다. 다음을 확인합니다.- API 프록시 내 정책
- 프록시에서 호출된 공유 흐름
흐름 변수
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 + pathurl = 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를 반환합니다.- scheme:
해상도
URL 사양
RFC 3986, 섹션 3: 문법 구성요소에 따라 path 구성요소는 필수이며 항상 '/'로 시작해야 합니다. 아래 단계에 따라 이 문제를 해결하세요.
- 흐름 변수
target.url로 표시된 백엔드 서버 URL에 항상 유효한 경로가 있고 항상 슬래시 (/)로 시작하는지 확인합니다.- 경로에 리소스 이름이 없는 경우 경로에 슬래시 (
/)가 하나 이상 있는지 확인합니다. - 다른 변수를 사용하여 흐름 변수
target.url의 값을 결정하는 경우 다른 변수에 잘못된 경로가 없는지 확인하세요. - 문자열 작업을 실행하여 흐름 변수
target.url의 값을 결정하는 경우 문자열 작업의 결과 또는 결과에 잘못된 경로가 없는지 확인합니다.
- 경로에 리소스 이름이 없는 경우 경로에 슬래시 (
위에서 설명한 샘플에서 다음과 같이 이 문제를 해결할 수 있습니다.
샘플 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
참조