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

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  43  44  [45]  ...
NoWriterDateCnt.TitleFile(s)
12520정성태1/30/20218643개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/20217679개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202125147Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202112816Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/20219426Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202110683웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202110935.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
12513정성태1/28/20218983오류 유형: 698. electronize - User Profile 디렉터리에 공백 문자가 있는 경우 빌드가 실패하는 문제 [1]
12512정성태1/28/20218720오류 유형: 697. The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.
12511정성태1/27/20218497Windows: 187. Windows - 도스 시절의 8.3 경로를 알아내는 방법
12510정성태1/27/20218918.NET Framework: 1020. .NET Core Kestrel 호스팅 - Razor 지원 추가 [1]파일 다운로드1
12509정성태1/27/20219814개발 환경 구성: 524. Jupyter Notebook에서 C#(F#, PowerShell) 언어 사용을 위한 환경 구성 [3]
12508정성태1/27/20218402개발 환경 구성: 523. Jupyter Notebook - Slide 플레이 버튼이 없는 경우
12507정성태1/26/20218512VS.NET IDE: 157. Visual Studio - Syntax Visualizer 메뉴가 없는 경우
12506정성태1/25/202111871.NET Framework: 1019. Microsoft.Tye 기본 사용법 소개 [1]
12505정성태1/23/20219500.NET Framework: 1018. .NET Core Kestrel 호스팅 - Web API 추가 [1]파일 다운로드1
12504정성태1/23/202110636.NET Framework: 1017. .NET 5에서의 네트워크 라이브러리 개선 (2) - HTTP/2, HTTP/3 관련 [1]
12503정성태1/21/20218981오류 유형: 696. C# - HttpClient: Requesting HTTP version 2.0 with version policy RequestVersionExact while HTTP/2 is not enabled.
12502정성태1/21/20219751.NET Framework: 1016. .NET Core HttpClient의 HTTP/2 지원파일 다운로드1
12501정성태1/21/20218791.NET Framework: 1015. .NET 5부터 HTTP/1.1, 2.0 선택을 위한 HttpVersionPolicy 동작 방식파일 다운로드1
12500정성태1/21/20219355.NET Framework: 1014. ASP.NET Core(Kestrel)의 HTTP/2 지원 여부파일 다운로드1
12499정성태1/20/202110579.NET Framework: 1013. .NET Core Kestrel 호스팅 - 포트 변경, non-localhost 접속 지원 및 https 등의 설정 변경 [1]파일 다운로드1
12498정성태1/20/20219576.NET Framework: 1012. .NET Core Kestrel 호스팅 - 비주얼 스튜디오의 Kestrel/IIS Express 프로파일 설정
12497정성태1/20/202110560.NET Framework: 1011. C# - OWIN Web API 예제 프로젝트 [1]파일 다운로드2
12496정성태1/19/20219450.NET Framework: 1010. .NET Core 콘솔 프로젝트에서 Kestrel 호스팅 방법 [1]
12495정성태1/19/202111371웹: 40. IIS의 HTTP/2 지원 여부 - h2, h2c [1]
... 31  32  33  34  35  36  37  38  39  40  41  42  43  44  [45]  ...