400 잘못된 요청 - DuplicateHeader

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

증상

클라이언트 애플리케이션이 오류 코드와 함께 HTTP 상태 코드 400 Bad Request를 가져옵니다. protocol.http.DuplicateHeader 를 API 호출에 대한 응답으로 사용합니다.

오류 메시지

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

HTTP/1.1 400 Bad Request

또한 아래와 유사한 오류 메시지가 표시될 수도 있습니다.

{
   "fault":{
      "faultstring":"Duplicate Header \"Expires\"",
      "detail":{
         "errorcode":"protocol.http.DuplicateHeader"
      }
   }
}

가능한 원인

이 오류는 Apigee에서 중복이 허용되지 않는 특정 HTTP 헤더가 있는 경우에 발생합니다. Edge는 HTTP 요청의 일부로 동일하거나 다른 값을 포함하여 두 번 이상 표시됩니다. Apigee Edge로 이동합니다

기준 RFC 7230, 섹션 3.2.2: 필드 순서, 발신자는 여러 헤더를 생성하면 안 됩니다(MUST NOT). 메시지에서 필드 이름이 동일한 필드 헤더 필드는 쉼표로 구분된 목록으로 정의됩니다(예: #(values)] 가 포함되어 있거나 헤더 필드가 잘 알려진 예외일 수 있습니다. Apigee Edge가 특정 헤더를 찾으면 해당 헤더는 HTTP 요청 에서 두 번 이상 중복될 경우 400 Bad Request 및 오류 코드로 응답 protocol.http.DuplicateHeader

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

이 오류가 발생할 수 있는 원인은 다음과 같습니다.

원인 설명 다음에 관한 문제 해결 안내
요청에 중복된 헤더가 있음 클라이언트 애플리케이션에서 Apigee로 보낸 HTTP 요청에 중복 헤더가 포함되어 있습니다. 에지 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

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

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. 시간을 기준으로 결함 코드를 표시합니다.
  7. 오류 코드가 있는 셀을 선택합니다. protocol.http.DuplicateHeader 다음과 같습니다.

  8. 오류 코드(protocol.http.DuplicateHeader)에 대한 정보는 다음과 같습니다. 표시됩니다.

    <ph type="x-smartling-placeholder">
  9. 로그 보기를 클릭하고 실패한 요청의 행을 펼칩니다.
  10. 로그 창에서 다음 세부정보를 확인합니다. <ph type="x-smartling-placeholder">
      </ph>
    1. 상태 코드: 400
    2. 오류 소스: apigee
    3. 오류 코드: protocol.http.DuplicateHeader.
  11. 결함 소스의 값이 apigee 또는 MP 이고 오류 코드의 값이 protocol.http.DuplicateHeader이면 클라이언트에 중복된 헤더가 포함되어 있습니다.

추적 도구

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

NGINX

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

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

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

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

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

  3. 특정 기간 동안 400 오류가 있는지 검색하여 확인합니다( 또는 여전히 실패하고 있는 요청이 있는지 400
  4. X-Apigee-fault-code에서 400 오류가 발견된 경우 protocol.http.DuplicateHeader의 값과 일치하는 경우 X-Apigee-fault-source.의 값을 결정합니다.

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

    NGINX 액세스 로그의 위 샘플 항목에서는 X-Apigee-에 대해 다음과 같은 값을 갖습니다. fault-codeX-Apigee-fault-source:

    응답 헤더
    X-Apigee-fault-code protocol.http.DuplicateHeader
    X-Apigee-fault-source MP

원인: 요청에 중복된 헤더가 있음

진단

  1. API를 사용하여 관찰된 오류의 결함 코드오류 소스 확인 일반적인 진단 단계에 설명된 대로 Monitoring 또는 NGINX에서 로그에 액세스합니다.
  2. 결함 소스의 값이 apigee 또는 MP이면 클라이언트 애플리케이션에서 Apigee로 보낸 요청에 중복된 항목이 포함되어 있음을 나타냅니다. 있습니다.
  3. 요청의 일부로 두 번 이상 전송되는 실제 헤더를 확인하려면 다음 방법 중 하나를 사용합니다.

    오류 메시지

    오류 메시지 사용

    1. Apigee Edge에서 수신된 전체 오류 메시지에 액세스할 수 있는 경우 faultstring를 참고하세요. faultstring에는 다음이 포함됩니다. 두 번 이상 전송된 헤더 이름입니다.

      샘플 오류 메시지:

      "faultstring":"Duplicate Header \"Expires\""
      
    2. 위의 오류 메시지에서 Expires 헤더가 두 번 이상 전송됩니다. faultstring

    실제 요청

    실제 요청 사용

    1. 클라이언트 애플리케이션이 수행한 실제 요청에 액세스할 수 있는 경우 다음 단계를 따르세요.

      1. 요청에 전달된 헤더 목록을 확인합니다.
      2. 특정 헤더가 같은 값 또는 다른 값으로 요청을 보낼 수 있다면 를 참조하세요.

      샘플 요청:

      curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
      

      위 예시 요청에서 헤더 Expires은 합니다. 따라서 이 요청은 400 Bad Request 오류와 함께 실패합니다. 오류 코드: protocol.http.DuplicateHeader

      <ph type="x-smartling-placeholder">
    2. 또는 클라이언트 로그에 액세스할 수 있는 경우 Apigee Edge에 전송된 실제 요청에 대한 정보와 두 번 이상 전송됩니다.

해상도

중복 수정

옵션 #1 [권장 옵션] 중복 헤더가 포함되지 않도록 클라이언트 애플리케이션 수정

<ph type="x-smartling-placeholder">
  1. 특정 클라이언트가 중복 헤더를 전송하는 이유를 분석합니다. 예를 들어 위의 경우에는 Expires입니다. API 프록시가 수락해도 되는지 확인 복사됩니다. 일반적으로 HTTP 사양에 따라 바람직하지 않음 RFC7230
  2. 원하지 않는 경우 중복 헤더를 전송하지 않도록 클라이언트 애플리케이션을 수정합니다.

    위에서 설명한 예에서는 Expires 헤더가 전송된다는 것을 알 수 있습니다. 이는 바람직하지 않습니다. 이 문제를 해결하려면 아래와 같이 Expires 헤더를 한 번만 사용하면 됩니다.

    curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
    
  3. 중복 헤더를 허용하려면 옵션 #2 CwC 속성 사용.

CwC

옵션 #2 CwC 속성 사용

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

Apigee는 CwC 속성 HTTPHeader.<HeaderName> - 클라이언트를 허용함 중복 헤더를 Apigee Edge의 API 프록시로 전송합니다.

CwC 속성
HTTPHeader.<HeaderName> allowDuplicates,multivalued

예를 들어, 다음 속성을 메시지 프로세서에 설정하여 중복 및 Expires 헤더에 값이 여러 개 있습니다.

HTTPHeader.Expires=allowDuplicates, multiValued
  1. Private Cloud 사용자인 경우 VPC 피어링을 방지하도록 속성을 요청이400 Bad Request 을(를) 사용하는 중복 헤더가 포함되어 있습니다. 중복 헤더를 사용하도록 메시지 프로세서 구성 안내 가이드
  2. 퍼블릭 클라우드 사용자인 경우 Apigee Edge 지원팀에 문의하여 이 속성을 구성하세요. 사용할 수 있습니다

사양

Apigee는 클라이언트 애플리케이션이 요청의 일부로 중복 헤더를 전송하지 않을 것으로 예상합니다. 를 사용합니다.

사양
<ph type="x-smartling-placeholder"></ph> RFC 7230, 섹션 3.2.2: 필드 순서
<ph type="x-smartling-placeholder"></ph> RFC 7230, 섹션 3.2 헤더 필드

Apigee 지원팀의 도움이 더 필요하면 다음 페이지로 이동하세요. 진단 정보를 수집해야 합니다.

진단 정보 수집 필요

다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 문의하세요.

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

  • 조직 이름
  • 환경 이름
  • API 프록시 이름
  • 400 오류를 재현하는 데 사용된 curl 명령어를 완료합니다.
  • API 요청에 대한 추적 파일

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

  • 실패한 요청에 대해 발견된 전체 오류 메시지
  • 환경 이름
  • API 프록시 번들
  • 400 오류를 재현하는 데 사용한 curl 명령어를 완료합니다.
  • 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