Microsoft MVP성태의 닷넷 이야기
.NET Framework: 226. HttpWebRequest 타입의 HaveResponse 속성 이야기 [링크 복사], [링크+제목 복사],
조회: 35014
글쓴 사람
정성태 (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)
13893정성태2/27/20252238Linux: 115. eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
13892정성태2/24/20252994닷넷: 2325. C# - PowerShell과 연동하는 방법파일 다운로드1
13891정성태2/23/20252510닷넷: 2324. C# - 프로세스의 성능 카운터용 인스턴스 이름을 구하는 방법파일 다운로드1
13890정성태2/21/20252337닷넷: 2323. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(Win32 API)파일 다운로드1
13889정성태2/20/20253071닷넷: 2322. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(성능 카운터, WMI) [1]파일 다운로드1
13888정성태2/17/20252501닷넷: 2321. Blazor에서 발생할 수 있는 async void 메서드의 부작용
13887정성태2/17/20253084닷넷: 2320. Blazor의 razor 페이지에서 code-behind 파일로 코드를 분리 및 DI 사용법
13886정성태2/15/20252577VS.NET IDE: 196. Visual Studio - Code-behind처럼 cs 파일을 그룹핑하는 방법
13885정성태2/14/20253243닷넷: 2319. ASP.NET Core Web API / Razor 페이지에서 발생할 수 있는 async void 메서드의 부작용
13884정성태2/13/20253527닷넷: 2318. C# - (async Task가 아닌) async void 사용 시의 부작용파일 다운로드1
13883정성태2/12/20253288닷넷: 2317. C# - Memory Mapped I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13882정성태2/10/20252588스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/20252839닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/20253183오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/20253424오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/20253199오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20253252닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20253716닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20253149스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20253572스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20252984디버깅 기술: 217. WinDbg - PCI 장치 열거파일 다운로드1
13872정성태1/23/20252902오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20253302Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20253752개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20253469개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20253119Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...