HTTP 414 URI Too Long: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 크롤러, 모니터링 도구 또는 검사기가 HTTP 414 URI Too Long 응답을 받습니다.
• 문제가 발생한 주소에 비정상적으로 긴 경로, 쿼리 문자열, 반복된 매개변수 또는 과도하게 인코딩된 데이터가 포함되어 있습니다.
• 짧은 URL은 계속 작동하는 반면 특정 링크, 경로, 리디렉션 체인 또는 요청 유형에만 문제가 발생할 수 있습니다.
• 리디렉션이 진행될 때마다 URL이 길어져 중간 장비 또는 원본 서버가 이를 거부할 수 있습니다.
• 응답 헤더에는 애플리케이션 자체가 아닌 웹 서버, reverse proxy, CDN, WAF 또는 캐싱 계층이 표시될 수 있습니다.
• 요청이 HTTP를 처리하는 엔드포인트에 도달했기 때문에 DNS 확인과 TLS 협상은 성공할 수 있습니다.

가능성이 높은 순서의 주요 원인

가장 가능성 높은 원인

1. 지나치게 큰 쿼리 문자열. 검색, 필터, 페이지네이션, 추적 또는 상태 매개변수가 엔드포인트가 허용하는 것보다 많은 데이터를 직렬화할 수 있습니다.
2. URL 생성 버그. 클라이언트 또는 서버 측 코드가 동일한 매개변수를 반복해서 추가하거나, 인코딩된 URL을 중복하거나, URI에 포함해서는 안 되는 데이터를 넣을 수 있습니다.
3. 계속 길어지는 리디렉션 체인. 리디렉션 대상이 반환 URL, 추적 매개변수 또는 원래 주소의 인코딩된 복사본을 반복해서 추가할 수 있습니다.
4. 프록시, CDN, WAF 또는 웹 서버의 제한. 요청이 애플리케이션에 도달하기 전에 거부될 수 있으며, 계층마다 URI 제한이 다를 수 있습니다.
5. 예상하지 못한 요청 구성. 잘못된 인코딩, 다른 매개변수 안에 실수로 포함된 절대 URL 또는 잘못 구성된 연동으로 인해 비정상적으로 긴 요청 대상이 생성될 수 있습니다.
6. 의도적인 요청 검증 또는 악용 방지. 리소스 소비를 줄이거나 의심스러운 트래픽을 차단하기 위해 구성 요소가 비정상적으로 큰 요청 대상을 거부할 수 있습니다.

해결 방법

방문자 및 API 사용자

1. 정확한 주소를 확인하세요. 반복된 쿼리 매개변수, 추적 데이터가 포함된 복사된 URL, 완료되지 않은 리디렉션 또는 예상보다 긴 인코딩 값을 확인합니다.
2. 안전한 경우 선택적 매개변수 없이 기본 경로를 열어 보세요. 짧은 주소가 작동한다면 필터 또는 매개변수를 소규모 그룹으로 다시 추가하여 문제를 일으키는 요소를 찾습니다.
3. 반복해서 새로 고침하지 마세요. 재시도해도 지나치게 긴 URI가 짧아지지 않으며, 리디렉션 또는 클라이언트 루프가 관련된 경우 부하가 증가할 수 있습니다.
4. 문서화된 요청 형식을 사용하세요. API가 큰 필터 또는 페이로드를 요청 본문으로 전송하는 방식을 지원한다면 문서에 명시된 대로만 사용하세요. 오류를 우회하기 위해 단순히 GET 요청을 POST로 변경하지 마세요.
5. 사이트 또는 API 운영자에게 문의하세요. 민감 정보를 삭제한 URL 또는 요청 패턴, 타임스탬프, 클라이언트 정보 및 414 응답을 전달합니다. 쿠키, authorization 헤더, API 키 및 기타 비밀 정보는 제거하세요.

개발자

1. 요청을 정확히 캡처하세요. HTTP 메서드, 호스트, 경로, 쿼리 문자열 길이, 리디렉션 이력, 최종 상태 코드 및 관련 응답 헤더를 기록합니다. 자격 증명과 개인정보는 삭제하거나 마스킹하세요.
2. 실패하는 요청을 최소 단위로 재현하세요. 응답이 변경될 때까지 선택적 매개변수를 하나씩 제거하거나 값을 짧게 만듭니다. 이를 통해 URI 크기 문제와 라우팅 또는 인증 오류를 구분할 수 있습니다.
3. URL 생성을 점검하세요. 검색 필터, 페이지네이션, 추적 매개변수, 반환 URL, 중첩 인코딩 및 현재 URL을 반복해서 추가하는 루프를 확인합니다.
4. 리디렉션을 검토하세요. 체인의 각 Location 값을 비교하고 이전 URL 또는 중복 매개변수를 계속 추가하지 않는지 확인합니다.
5. 적절한 데이터 전송 방식을 선택하세요. 안전하고 캐시 가능한 리소스 조회에 필요한 식별자는 URI에 유지하되, 의미와 보안 모델이 허용하는 경우 더 큰 입력에는 애플리케이션이 지원하는 요청 본문 방식을 사용합니다.
6. 응답을 생성한 계층을 확인하세요. 타임스탬프와 요청 세부 정보를 애플리케이션, 웹 서버, reverse proxy, CDN 및 WAF 로그와 대조합니다. 거부를 기록한 첫 번째 구성 요소가 일반적으로 조사해야 할 계층입니다.
7. 가장 좁은 범위로 수정하세요. 서버 또는 중간 장비의 제한을 변경하기 전에 URL 생성, 리디렉션 로직 또는 매개변수 처리를 수정합니다. 제한을 변경해야 한다면 승인을 받고 리소스 및 보안 영향을 평가한 후 올바른 계층을 업데이트하고 대표적인 경로를 테스트하세요.
8. 원래 요청과 인접 사례를 다시 테스트하세요. 의도한 요청이 성공하고, 잘못되었거나 과도한 요청이 계속 통제되며, 리디렉션이 종료되고, 관련 없는 경로가 예상 상태 코드를 유지하는지 확인합니다.

예방 및 해결 확인 방법

• 애플리케이션 검증에서 쿼리 매개변수 개수와 값의 길이에 제한을 설정하세요.
• 리디렉션 코드가 현재 URL을 반복해서 중첩하거나 다시 인코딩하지 않도록 하세요.
• 통합 테스트에서 긴 필터, 페이지네이션, 추적 매개변수 및 리디렉션 체인을 테스트하세요.
• 지원되는 경우 프록시, CDN, WAF, 웹 서버 및 애플리케이션 설정을 문서화하고 버전 관리하세요.
• 경로, 클라이언트 및 배포별로 414 응답을 모니터링하여 URL 생성 회귀를 확인할 수 있도록 하세요.
• 큰 데이터를 URL에 인코딩하는 대신 대규모 애플리케이션 입력에는 지원되는 요청 본문 방식을 우선 사용하세요.
• 자격 증명이나 민감한 데이터를 URL에 넣지 마세요. 이러한 정보는 방문 기록, 로그 또는 referrer 데이터에 나타날 수 있습니다.

자주 묻는 질문