Microsoft MVP성태의 닷넷 이야기
.NET Framework: 226. HttpWebRequest 타입의 HaveResponse 속성 이야기 [링크 복사], [링크+제목 복사],
조회: 27806
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13240정성태2/1/20234165디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233840디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20235947.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235631.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20235162개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234742개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235851개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20237235오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234944스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233939오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234303개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20235295.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235398.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20235085개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234770.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233955개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234369Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234545오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234252개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234460Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234540오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20234155Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20234078VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234675디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20234932디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
13215정성태1/11/20236581Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법 [1]
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...