Share via

IIS에서 HTTP 400 오류 문제 해결

  • 아티클

적용 대상: 인터넷 정보 서비스

이 문서에서는 IIS를 사용할 때 다양한 HTTP 400 오류의 원인을 식별하는 문제 해결 단계를 설명합니다.

개요

IIS 서버에 HTTP 요청을 보낸 후 HTTP 클라이언트(예: 인터넷 Explorer)에서 다음과 같은 유형의 오류 메시지를 표시할 수 있습니다.

HTTP 400웹 페이지를 찾을 수 없습니다.

가장 가능성이 높은 원인은 다음과 같습니다.

  • 주소에 입력 오류가 있을 수 있습니다.
  • 링크를 클릭하면 오래된 것일 수 있습니다.

시도할 수 있는 사항:

  • 주소를 다시 입력합니다.
  • 이전 페이지로 돌아가기.
  • Bing으로 이동하여 원하는 정보를 찾습니다.

HTTP 클라이언트가 인터넷 Explorer 있고 친숙한 HTTP 오류 메시지 표시 옵션이 꺼져 있는 경우 오류는 다음과 유사할 수 있습니다.

잘못된 요청

이러한 시나리오에서 IIS는 요청이 서버의 HTTP 구문 분석 규칙을 충족하지 못했거나 시간 제한을 초과했거나 IIS 또는 HTTP.sys 들어오는 요청을 준수해야 하는 다른 규칙에 실패했기 때문에 클라이언트의 HTTP 요청을 거부했습니다. IIS는 "HTTP 400 - 잘못된 요청" 상태 클라이언트로 다시 보낸 다음 TCP 연결을 종료합니다.

도구

문제 해결 방법

HTTP 400 조건 문제를 해결할 때 기본 문제는 클라이언트가 HTTP.sys 적용되는 하나 이상의 규칙을 위반하는 요청을 IIS에 보냈다는 것입니다. 이 점을 염두에 두고 클라이언트가 IIS에 보내는 내용을 정확하게 확인할 수 있습니다. 이렇게 하려면 잘못된 요청을 보내는 클라이언트의 네트워크 추적을 캡처합니다. 추적을 분석하여 클라이언트가 IIS에 보내는 원시 데이터를 확인하고 IIS가 클라이언트로 다시 보내는 원시 응답 데이터를 볼 수 있습니다. 클라이언트와 서버가 SSL을 통해 통신하는 경우에도 HTTP 헤더를 볼 수 있는 훌륭한 도구인 Fiddler라는 HTTP 스니퍼 도구를 사용할 수도 있습니다.

사용하는 다음 데이터 항목은 C:\Windows\System32\LogFiles\HTTPERR\httperr.log 파일입니다. IIS 6.0부터 HTTP.sys 구성 요소는 들어오는 HTTP 요청을 IIS에 전달하기 전에 처리하며 IIS 요구 사항을 충족하지 않는 요청을 차단하는 구성 요소입니다. HTTP.sys 요청을 차단하면 잘못된 요청 및 차단된 이유와 관련된 정보를 httperr.log 파일에 기록합니다.

참고: HTTP.sys 제공하는 HTTP API 오류 로깅에 대한 자세한 내용은 HTTP API에서 오류 로깅을 참조하세요.

기술적으로는 가능하지만 클라이언트가 HTTP 400 응답을 받을 수 있으며, 이 응답에는 httperr.log 연결된 로그 항목이 없습니다. ISAPI 필터 또는 확장 또는 IIS의 HTTP 모듈이 400 상태 설정하는 경우 발생할 수 있습니다. 이 경우 IIS 로그에서 자세한 내용을 확인할 수 있습니다. 프록시 서버 또는 다른 네트워크 디바이스와 같이 클라이언트와 서버 간의 엔터티가 IIS의 응답을 가로채 자체 400 상태 및/또는 "잘못된 요청" 오류로 재정의하는 경우에도 발생할 수 있습니다.

샘플 시나리오

다음은 클라이언트가 IIS에 잘못된 요청을 보내고 서버가 "HTTP 400 - 잘못된 요청" 메시지를 다시 보내는 HTTP 400 시나리오의 예입니다.

클라이언트가 요청을 보내면 다시 가져오는 브라우저 오류는 다음과 같습니다.

잘못된 요청(헤더 필드가 너무 깁니다.)

요청 및 응답의 네트워크 추적을 캡처하면 다음 출력이 표시됩니다.

요청:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

응답:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

응답 헤더는 브라우저의 오류 메시지만큼 많이 표시되지 않습니다. 그러나 응답 본문에서 원시 데이터를 보면 다음이 더 표시됩니다.

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

브라우저에 표시되는 오류 메시지 텍스트는 네트워크 추적의 원시 응답 데이터에서도 볼 수 있습니다.

다음 단계는 C:\Windows\System32\LogFiles\HTTPERR 디렉터리에서 잘못된 요청에 해당하는 항목에 대한 httperr.log 파일을 살펴보는 것입니다.

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

이 시나리오 Reason 에서 httperr.log 파일의 필드는 문제를 진단하는 데 필요한 정확한 정보를 제공합니다. 이 HTTP.sys 이 요청 실패의 원인 구로 기록된 FieldLength 것을 볼 수 있습니다. 이유 구를 알고 나면 HTTP API에서 로그하는 오류 종류 섹션의 테이블을 검사 설명을 가져옵니다.

FieldLength: 필드 길이 제한을 초과했습니다.

따라서 이 시점에서 브라우저 오류 메시지 및 HTTP API 오류 로깅에서 요청이 허용 길이 제한을 초과하는 HTTP 헤더 중 하나에 데이터를 포함했음을 알 수 있습니다. 이 예제의 HTTP: Uniform Resource Identifier header 경우 은 의도적으로 깁니다. /1234567890123456789012345678901234567890/time.asp.

이 예제 문제 해결의 마지막 단계는 IIS에 대한 HTTP.sys 레지스트리 키 및 기본 설정을 검사 것입니다.

구와 오류가 머리글 필드 길이가 제한을 초과하는 것을 제안하는 이유를 알고 있으므로 레지스트리 키 테이블에서 검색 범위를 좁힐 수 있습니다. 주요 후보는 다음과 같습니다.

레지스트리 키 기본값 유효한 값 범위 레지스트리 키 함수 경고 코드
MaxFieldLength 16384 64 - 65534(64k - 2) 바이트 각 헤더에 대한 상한을 설정합니다. MaxRequestBytes를 참조하세요. 이 제한은 URL에 대해 약 32k 문자로 변환됩니다. 1

이 예제 MaxFieldLength 에 대해 이 오류를 재현하기 위해 레지스트리 키가 값 2로 설정되었습니다. 요청된 URL에 두 개 이상의 문자가 있는 HTTP: Uniform Resource Identifier header 필드가 있으므로 요청이 이유 구로 FieldLength 차단되었습니다.

또 다른 일반적인 HTTP 400 시나리오는 HTTP 요청을 하는 사용자가 많은 수의 Active Directory 그룹의 구성원이며 웹 사이트가 사용자 Kerberos 인증으로 구성된 시나리오입니다. 이 경우 다음과 유사한 오류 메시지가 사용자에게 표시됩니다.

잘못된 요청(요청 헤더가 너무 깁니다.)

이 시나리오에서는 클라이언트의 HTTP 요청의 일부로 포함된 인증 토큰이 너무 커서 http.sys 적용되는 크기 제한을 초과합니다. 이 문제는 솔루션과 함께 HTTP 요청에 대한 HTTP 400 - 잘못된 요청(요청 헤더가 너무 깁니다) 응답에서 자세히 설명합니다.

참조