Microsoft MVP성태의 닷넷 이야기
.NET Framework: 226. HttpWebRequest 타입의 HaveResponse 속성 이야기 [링크 복사], [링크+제목 복사],
조회: 27778
글쓴 사람
정성태 (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)
13487정성태12/16/20232411개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [1]
13486정성태12/15/20232225개발 환경 구성: 695. Nuget config 파일에 값 설정/삭제 방법
13485정성태12/15/20232103오류 유형: 883. dotnet build/restore - error : Root element is missing
13484정성태12/14/20232182개발 환경 구성: 694. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법
13483정성태12/14/20232326닷넷: 2184. C# - 하나의 resource 파일을 여러 프로그램에서 (AOT 시에도) 사용하는 방법파일 다운로드1
13482정성태12/13/20232983닷넷: 2183. C# - eFriend Expert OCX 예제를 .NET Core/5+ Console App에서 사용하는 방법 [2]파일 다운로드1
13481정성태12/13/20232301개발 환경 구성: 693. msbuild - .NET Core/5+ 프로젝트에서 resgen을 이용한 리소스 파일 생성 방법파일 다운로드1
13480정성태12/12/20232691개발 환경 구성: 692. Windows WSL 2 + Chrome 웹 브라우저 설치
13479정성태12/11/20232363개발 환경 구성: 691. WSL 2 (Ubuntu) + nginx 환경 설정
13477정성태12/8/20232594닷넷: 2182. C# - .NET 7부터 추가된 Int128, UInt128 [1]파일 다운로드1
13476정성태12/8/20232302닷넷: 2181. C# - .NET 8 JsonStringEnumConverter의 AOT를 위한 개선파일 다운로드1
13475정성태12/7/20232387닷넷: 2180. .NET 8 - 함수 포인터에 대한 Reflection 정보 조회파일 다운로드1
13474정성태12/6/20232207개발 환경 구성: 690. 닷넷 코어/5+ 버전의 ilasm/ildasm 실행 파일 구하는 방법 - 두 번째 이야기
13473정성태12/5/20232448닷넷: 2179. C# - 값 형식(Blittable)을 메모리 복사를 이용해 바이트 배열로 직렬화/역직렬화파일 다운로드1
13472정성태12/4/20232230C/C++: 164. Visual C++ - InterlockedCompareExchange128 사용 방법
13471정성태12/4/20232315Copilot - To enable GitHub Copilot, authorize this extension using GitHub's device flow
13470정성태12/2/20232665닷넷: 2178. C# - .NET 8부터 COM Interop에 대한 자동 소스 코드 생성 도입파일 다운로드1
13469정성태12/1/20232424닷넷: 2177. C# - (Interop DLL 없이) CoClass를 이용한 COM 개체 생성 방법파일 다운로드1
13468정성태12/1/20232327닷넷: 2176. C# - .NET Core/5+부터 달라진 RCW(Runtime Callable Wrapper) 대응 방식파일 다운로드1
13467정성태11/30/20232418오류 유형: 882. C# - Unhandled exception. System.Runtime.InteropServices.COMException (0x800080A5)파일 다운로드1
13466정성태11/29/20232594닷넷: 2175. C# - DllImport 메서드의 AOT 지원을 위한 LibraryImport 옵션
13465정성태11/28/20232338개발 환경 구성: 689. MSBuild - CopyToOutputDirectory가 "dotnet publish" 시에는 적용되지 않는 문제파일 다운로드1
13464정성태11/28/20232462닷넷: 2174. C# - .NET 7부터 UnmanagedCallersOnly 함수 export 기능을 AOT 빌드에 통합파일 다운로드1
13463정성태11/27/20232396오류 유형: 881. Visual Studio - NU1605: Warning As Error: Detected package downgrade
13462정성태11/27/20232399오류 유형: 880. Visual Studio - error CS0246: The type or namespace name '...' could not be found
13461정성태11/26/20232439닷넷: 2173. .NET Core 3/5+ 기반의 COM Server를 registry 등록 없이 사용하는 방법파일 다운로드1
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...