Microsoft MVP성태의 닷넷 이야기
.NET Framework: 226. HttpWebRequest 타입의 HaveResponse 속성 이야기 [링크 복사], [링크+제목 복사],
조회: 35021
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

HttpWebRequest 타입의 HaveResponse 속성 이야기


기본적으로 ASP.NET 웹 사이트를 생성하면 업로드 데이터 제한이 2개의 조건에 의해서 걸려 있습니다.

<system.web>
    <httpRuntime maxRequestLength="4096" /> <!-- KB 단위 -->
</system.web>

<system.webServer>
    <security>
        <requestFiltering>
            <requestLimits maxAllowedContentLength="30000000"/>  <!-- Bytes 단위 -->
        </requestFiltering>
    </security>
</system.webServer>

maxRequestLength 값으로 4MB, maxAllowedContentLength로 (30000000 / 1024) ≒ 29,296KB ≒ 28MB이니, 결론적으로 4MB 이상 업로드할 수 없습니다. 만약 이를 넘어가면 웹 브라우저의 경우 다음과 같은 오류가 발생합니다.

Maximum request length exceeded. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Maximum request length exceeded.


반면에, maxAllowedContentLength 제한에 걸리면 다음과 같이 구분이 됩니다.

HTTP Error 404.13 - Not Found The request filtering module is configured to deny a request that exceeds the request content length.Most likely causes:
Request filtering is configured on the Web server to deny the request because the content length exceeds the configured value.
Things you can try:
Verify the configuration/system.webServer/security/requestFiltering/requestLimits@maxAllowedContentLength setting in the applicationhost.config or web.config file.
Detailed Error Information:
Module RequestFilteringModule
Notification BeginRequest
Handler PageHandlerFactory-Integrated-4.0
Error Code 0x00000000
...[생략]...
More Information:
This is a security feature. Do not change this feature unless the scope of the change is fully understood. You can configure the IIS server to reject requests whose content length is greater than a specified value. If the request's content length is greater than the configured length, this error is returned. If the content length requires an increase, modify the configuration/system.webServer/security/requestFiltering/requestLimits@maxAllowedContentLength setting.





보통, 닷넷에서 웹 서버와 가볍게 통신을 할 때 HttpWebRequest를 사용하는데, 다음은 이에 대한 간단한 예제입니다. (예제를 간결하게 하기 위해 "multipart/form-data"에 대한 정확한 코드는 생략했지만, 첨부파일에는 포함되어 있습니다.)

static void Main(string[] args)
{
    string url = "...";
    HttpWebRequest req = WebRequest.Create(url) as HttpWebRequest;

    string formBoundary = Guid.NewGuid().ToString();
    string contentType = "multipart/form-data; boundary=" + formBoundary;

    int reqSize = 1024 * 1024 * 5; // 5MB
    req.ContentLength = reqSize;
    req.Method = "POST";
    req.ContentType = contentType;

    byte []testBytes = new byte[reqSize];

    Stream stream = req.GetRequestStream();

    // ... [생략: multipart/form-data에 기반한 파일 전송] ...
    stream.Write(testBytes, 0, testBytes.Length);
    stream.Close();

    HttpWebResponse resp = req.GetResponse() as HttpWebResponse;
    using (StreamReader sr = new StreamReader(resp.GetResponseStream()))
    {
        string result = sr.ReadToEnd();
        Console.WriteLine(result);
    }
}

위의 경우에, 5MB 용량을 업로드하게 되어 있는데요. 직접 실행해보면, 웹 서버 측의 업로드 용량 제한으로 인해 오류가 발생하게 되는데, 예상과는 달리 예외가 발생하는 코드의 위치가 GetResponse 메서드를 호출하는 부분입니다.

즉, GetRequestStream으로 반환받은 Stream에 5MB를 전부 쓸 때까지 아무런 보고도 없는 것입니다. (만약, 업로드 용량이 5GB였다면 어떨까요? ^^) 반면에, 재미있게도 웹 브라우저로 테스트 해보면 곧바로 용량 제한에 걸렸다는 메시지가 떨어지면서 제어가 반환되는 것을 볼 수 있습니다.

이 정도 되면 눈치채셨겠지만, 바로 이런 경우에 웹 서버로부터의 조기 결과 반환 여부를 알기 위해 HttpWebRequest.HaveResponse 속성을 사용할 수 있습니다. 단순한 실험값에 의하면 적절한 사용 지점은 GetRequestStream 이후라면 어디든 상관없었습니다.

Stream stream = req.GetRequestStream();

if (req.HaveResponse == true)
{
    // 서버로부터 용량 제한에 걸렸을 가능성이 있음.
    return;
}

참고로, (위의 예제에서 업로드 용량을 1MB로 내려서) 정상적으로 요청이 이뤄졌을 때에도 req.GetResponse 메서드가 실행되면 HaveResponse 속성값은 true로 바뀝니다.




한 가지 아쉬운 점이 있다면, (비정상적인) HaveResponse == true인 상황에서 HttpWebRequest 개체의 Socket 개체 정리가 불완전하다는 면이 있습니다. 테스트를 위해, 위의 코드에서 KeepAlive 속성을 false로 설정하고 프로세스 종료를 막기 위해 Console.ReadLine을 호출해 줍니다.

req.ContentType = contentType;
req.KeepAlive = false;

...[생략]...

if (req.HaveResponse == true)
{
    Console.WriteLine("req.HaveResponse == true");
    Console.ReadLine();
    return;
}

위와 같이 변경하고, 예제 프로그램을 실행한 다음 곧바로 명령행 윈도우에서 netstat로 확인해 보면 소켓이 CLOSE_WAIT 상태에 빠져 있는 것을 확인할 수 있습니다.

C:>netstat -ano | findstr "6000"
  TCP    192.168.0.95:13256     192.168.90.210:6000    CLOSE_WAIT      2500

만약, 업로드 용량을 1MB로 변경하고 다시 시도해 보면, CLOSE_WAIT 상태의 소켓이 없는 것을 확인할 수 있습니다. 그런데, 이게 왜 문제가 되는 것일까요? ^^

재현을 위해, 다시 다음과 같이 전체 소스 코드에 for 문을 3번 실행되도록 변경을 해봅니다.

static void Main(string[] args)
{
    for (int i = 0; i < 3; i++)
    {
        DoRequest();
        Console.WriteLine(DateTime.Now + " - Count: " + (i + 1).ToString());
    }
}
        
static void DoRequest()
{
    string url = "http://.../UploadTest.aspx";
    HttpWebRequest req = WebRequest.Create(url) as HttpWebRequest;

    ...[생략]...

    if (req.HaveResponse == true)
    {
        Console.WriteLine("req.HaveResponse == true");
        return;
    }

    ...[생략]...
}

실행해 보면, 용량 초과로 인해 2번의 HttpWebRequest 실패가 발생하고, 따라서 2개의 소켓이 CLOSE_WAIT 상태로 머물게 되어 3번째 HttpWebRequest.GetRequestStream 호출에서 더 이상의 가용한 연결 소켓이 없어서 HttpWebRequest.Timeout(기본값 100,000 ms == 1분 40초)만큼 스레드가 잠긴 후 예외가 발생합니다. 아래의 화면은 이를 테스트한 것입니다.

req.HaveResponse == true
2011-06-24 오후 10:07:46 - Count: 1

req.HaveResponse == true
2011-06-24 오후 10:07:46 - Count: 2
...[1분 40초 동안 스레드 잠김]...
Unhandled Exception: System.Net.WebException: The operation has timed out
   at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
   at System.Net.HttpWebRequest.GetRequestStream()
   at ConsoleApplication1.Program.DoRequest() in D:\...[생략]...\Program.cs:line 56
   at ConsoleApplication1.Program.Main(String[] args) in D:\...[생략]...\Program.cs:line 17
Press any key to continue . . .

아니, 그런데 "더 이상의 가용한 연결 소켓"이 없다는 것이 무슨 의미인가요? 라고 물으실 분들이 계실텐데요. 웹 브라우저들이 '특정 웹 사이트'에 대해 HTTP 동시 연결을 제한하는 것처럼, 닷넷의 경우에도 기본적으로 ServicePoint에 대해 2개 이상의 연결 개체가 넘지 않도록 제한하는 설정이 되어 있습니다. 따라서, 위와 같이 3번의 루프를 도는 경우에 스레드 블로킹에 걸리지 않으려면 다음과 같이 기본 동시 연결 수를 조정해 주어야 합니다.

ServicePointManager.DefaultConnectionLimit = 3;

물론, 이렇게 되면 3개의 CLOSE_WAIT 상태의 소켓이 남게 됩니다. 아무튼, 이런 상황은 HttpWebRequest 개체가 HaveResponse == true인 상황을 만났을 때 정상적으로 소켓을 닫는 작업을 못했기 때문에 발생합니다.

첨부된 파일은 위의 예제 코드를 담고 있습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 11/10/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13843정성태12/13/20244393오류 유형: 938. Docker container 내에서 빌드 시 error MSB3021: Unable to copy file "..." to "...". Access to the path '...' is denied.
13842정성태12/12/20244544디버깅 기술: 205. Windbg - KPCR, KPRCB
13841정성태12/11/20244868오류 유형: 937. error MSB4044: The "ValidateValidArchitecture" task was not given a value for the required parameter "RemoteTarget"
13840정성태12/11/20244453오류 유형: 936. msbuild - Your project file doesn't list 'win' as a "RuntimeIdentifier"
13839정성태12/11/20244885오류 유형: 936. msbuild - error CS1617: Invalid option '12.0' for /langversion. Use '/langversion:?' to list supported values.
13838정성태12/4/20244610오류 유형: 935. Windbg - Breakpoint 0's offset expression evaluation failed.
13837정성태12/3/20245090디버깅 기술: 204. Windbg - 윈도우 핸들 테이블 (3) - Windows 10 이상인 경우
13836정성태12/3/20244636디버깅 기술: 203. Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)
13835정성태12/2/20245086오류 유형: 934. Azure - rm: cannot remove '...': Directory not empty
13834정성태11/29/20245347Windows: 275. C# - CUI 애플리케이션과 Console 윈도우 (Windows 10 미만의 Classic Console 모드인 경우) [1]파일 다운로드1
13833정성태11/29/20244998개발 환경 구성: 737. Azure Web App에서 Scale-out으로 늘어난 리눅스 인스턴스에 SSH 접속하는 방법
13832정성태11/27/20244947Windows: 274. Windows 7부터 도입한 conhost.exe
13831정성태11/27/20244398Linux: 111. eBPF - BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_MAP_TYPE_RINGBUF에 대한 다양한 용어들
13830정성태11/25/20245244개발 환경 구성: 736. 파이썬 웹 앱을 Azure App Service에 배포하기
13829정성태11/25/20245195스크립트: 67. 파이썬 - Windows 버전에서 함께 설치되는 py.exe
13828정성태11/25/20244453개발 환경 구성: 735. Azure - 압축 파일을 이용한 web app 배포 시 디렉터리 구분이 안 되는 문제파일 다운로드1
13827정성태11/25/20245119Windows: 273. Windows 환경의 파일 압축 방법 (tar, Compress-Archive)
13826정성태11/21/20245365닷넷: 2313. C# - (비밀번호 등의) Console로부터 입력받을 때 문자열 출력 숨기기(echo 끄기)파일 다운로드1
13825정성태11/21/20245685Linux: 110. eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
13824정성태11/20/20244755Linux: 109. eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
13823정성태11/20/20245311개발 환경 구성: 734. Ubuntu에 docker, kubernetes (k3s) 설치
13822정성태11/20/20245192개발 환경 구성: 733. Windbg - VirtualBox VM의 커널 디버거 연결 시 COM 포트가 없는 경우
13821정성태11/18/20245112Linux: 108. Linux와 Windows의 프로세스/스레드 ID 관리 방식
13820정성태11/18/20245268VS.NET IDE: 195. Visual C++ - C# 프로젝트처럼 CopyToOutputDirectory 항목을 추가하는 방법
13819정성태11/15/20244506Linux: 107. eBPF - libbpf CO-RE의 CONFIG_DEBUG_INFO_BTF 빌드 여부에 대한 의존성
13818정성태11/15/20245320Windows: 272. Windows 11 24H2 - sudo 추가
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...