응답입니다.종료()가 유해하다고 간주됩니까?

응답입니다.종료()가 유해하다고 간주됩니까?

이 KB 문서에는 ASP.NET의Response.End()스레드를 중단합니다.

Reflector는 다음과 같이 표시됩니다.

public void End()
{
    if (this._context.IsInCancellablePeriod)
    {
        InternalSecurityPermissions.ControlThread.Assert();
        Thread.CurrentThread.Abort(new HttpApplication.CancelModuleException(false));
    }
    else if (!this._flushing)
    {
        this.Flush();
        this._ended = true;
        if (this._context.ApplicationInstance != null)
        {
            this._context.ApplicationInstance.CompleteRequest();
        }
    }
}

이것은 저에게 꽤 가혹한 것처럼 보입니다.KB 기사에 따르면 앱의 코드는 다음과 같습니다.Response.End()사형은 집행되지 않을 것이며, 그것은 최소한의 경악의 원칙을 위반하는 것입니다.거의.Application.Exit()WinForms 앱에서.스레드 중단 예외는 다음으로 인해 발생합니다.Response.End()잡을 수 없기 때문에 코드를 a로 둘러싸십시오.try...finally만족하지 못할 겁니다

내가 항상 피해야만 하는지 의문이 들게 합니다.Response.End().

혹시 제가 언제 사용해야 하는지 제안해주실 수 있나요?Response.End(),언제Response.Close()그리고 언제HttpContext.Current.ApplicationInstance.CompleteRequest()?

ref: Rick Strahl의 블로그 엔트리.

---

제가 받은 의견에 따르면, 제 대답은 "네, 해롭지만 일부 제한된 경우에 유용합니다.

• 사용하다Response.End()잡을 수 없는 던지기로서, 즉시 종료하기 위해.HttpResponse예외적인 조건으로디버깅하는 동안에도 유용할 수 있습니다.일상적인 응답을 완료하지 않도록 합니다.
• 사용하다Response.Close()클라이언트와의 연결을 즉시 종료합니다.이 MSDN 블로그 게시물에 따르면 이 방법은 일반적인 HTTP 요청 처리를 위한 것이 아닙니다.당신이 이 방법을 부를 만한 충분한 이유가 있을 가능성은 매우 낮습니다.
• 사용하다CompleteRequest()정상적인 요청을 종료합니다. CompleteRequestASP.NET 파이프라인을 앞으로 이동시킵니다.EndRequest이벤트, 전류 이후HttpApplication이벤트가 완료됩니다.그래서 전화를 하면,CompleteRequest그런 다음 응답에 더 많은 내용을 쓰면 쓰기가 클라이언트로 전송됩니다.

---

편집 - 2011년 4월 13일

자세한 내용은 여기에서 확인할 수 있습니다.

• MSDN 블로그의 유용한 게시물
• 존 리드의 유용한 분석

TL;DR

처음에는 [Response]에 대한 모든 통화를 간단히 교체할 것을 권장했습니다.[...] CompleteRequest() 호출로 종료]하지만, 포스트백 처리 및 HTML 렌더링을 방지하려면 [...] 재정의도 추가해야 합니다.

존 리드, "최종 분석"

---

MSDN, Jon Reid 및 Alain Renon에 따라:

ASP.NET 성능 - 예외 관리 - 예외를 피하는 코드 쓰기

서버.전송, 응답.리디렉션, 응답.종료 메서드는 모두 예외를 발생시킵니다.이러한 각 메서드는 내부적으로 응답을 호출합니다.끝. 응답에 대한 호출.End는 ThreadAbortException 예외를 발생시킵니다.

스레드 중단 예외 솔루션

HttpApplication.CompleteRequest()는 스레드가 페이지 이벤트 체인이 아닌 응용 프로그램 이벤트 체인의 HttpApplication 이벤트 파이프라인 [--]에서 대부분의 이벤트를 건너뛰도록 하는 변수를 설정합니다.

...

이벤트를 처리하거나 페이지를 렌더링하기 전에 페이지가 종료되어야 하는지 여부를 플래그 지정하는 클래스 수준 변수를 만듭니다. [...] RaisePostBackEvent 및 Render 메서드를 재정의하는 것이 좋습니다.

대답.종료 및 응답.닫기는 성능이 중요한 경우 일반 요청 처리에서 사용되지 않습니다.대답.End는 관련 성능 저하와 함께 요청 처리를 종료하는 편리하고 강력한 수단입니다.대답.닫기는 IIS/소켓 수준에서 HTTP 응답을 즉시 종료하기 위한 것이며 KeepAlive와 같은 문제가 발생합니다.

ASP.NET 요청을 종료하는 권장 방법은 HttpApplication입니다.요청 완료.HttpApplication 이후 ASP.NET 렌더링은 수동으로 건너뜁니다.CompleteRequest는 ASP.NET 페이지 파이프라인(앱 파이프라인의 한 단계)이 아닌 나머지 IIS/ASP.NET 응용 프로그램 파이프라인을 건너뜁니다.

---

코드

Copyright © 2001-2007, C6 Software, Inc. 내가 아는 한.

---

언급

HttpApplication.요청 완료

ASP.NET이 HTTP 파이프라인 실행 체인의 모든 이벤트 및 필터링을 무시하고 EndRequest 이벤트를 직접 실행하도록 합니다.

대답.끝.

이 방법은 ASP와의 호환성, 즉 ASP.NET.Preced ASP 이전의 COM 기반 웹 프로그래밍 기술과의 호환성을 위해 제공됩니다.NET. [강조 추가]

대답.가까운.

이 방법은 클라이언트에 대한 연결을 갑자기 종료하며 일반 HTTP 요청 처리를 위한 것이 아닙니다.[강조 추가]

이 질문은 응답에 대한 모든 구글 검색의 맨 위에 표시됩니다. 따라서 ASPX 페이지 전체를 렌더링하지 않고 이벤트에 대한 응답으로 CSV/XML/PDF 등을 게시하려는 저와 같은 다른 검색의 경우 이렇게 합니다. (이러한 간단한 작업 IMO에 대해 렌더 메서드를 재정의하는 것은 지나치게 복잡합니다.)

// Add headers for a csv file or whatever
Response.ContentType = "text/csv"
Response.AddHeader("Content-Disposition", "attachment;filename=report.csv")
Response.AddHeader("Pragma", "no-cache")
Response.AddHeader("Cache-Control", "no-cache")

// Write the data as binary from a unicode string
Dim buffer As Byte()
buffer = System.Text.Encoding.Unicode.GetBytes(csv)
Response.BinaryWrite(buffer)

// Sends the response buffer
Response.Flush()

// Prevents any other content from being sent to the browser
Response.SuppressContent = True

// Directs the thread to finish, bypassing additional processing
HttpContext.Current.ApplicationInstance.CompleteRequest()

앱에 예외 로거를 사용한 경우 해당 로거는 다음과 같이 희석됩니다.ThreadAbortException이 양성으로부터 s.Response.End()전화를 합니다. 이것이 마이크로소프트의 "Knock it off!"라고 말하는 방식이라고 생각합니다.

나는 단지 사용할 것입니다.Response.End()예외적인 조건이 있고 다른 조치가 가능하지 않은 경우.그러면 이 예외를 기록하면 실제로 경고가 표시될 수 있습니다.

"저는 여전히 응답 간의 차이를 모릅니다.요청 닫기 및 완료()"라고 말할 수 있습니다.

CompleteRequest()를 선호합니다. 응답을 사용하지 마십시오.닫기().

이 사례에 대한 자세한 요약은 다음 문서를 참조하십시오.

CompleteRequest()를 호출한 후에도 일부 텍스트(예: ASPX 코드에서 Redundered)가 응답 출력 스트림에 추가됩니다.다음 문서에 설명된 대로 Render 및 RaisePostBackEvent 메서드를 재정의하여 이를 방지할 수 있습니다.

BTW: 저는 응답 사용을 방지하는 것에 동의합니다.종료(), 특히 파일 다운로드를 에뮬레이트하기 위해 http 스트림에 데이터를 쓸 때.응답을 사용했습니다.로그 파일이 ThreadAbortExceptions로 가득 찰 때까지 과거()를 종료합니다.

저는 "반응"이라는 말에 동의하지 않습니다.끝은 해롭습니다."그것은 확실히 해롭지 않습니다.대답.종료는 지정된 대로 수행하고 페이지 실행을 종료합니다.리플렉터를 사용하여 구현 방법을 확인하는 것은 유용한 것으로 간주되어야 합니다.

---

나의 2센트 추천
사용을 피합니다.Response.End()제어 흐름으로서.
DO 사용Response.End()요청 실행을 중지하고 (일반적으로)* 어떤 코드도 해당 지점을 지나 실행되지 않는다는 것을 알아야 하는 경우.

---

*Response.End()및 ThreadAbortExceptions(스레드AbortExceptions).

Response.End()현재 구현의 일부로 ThreadAbortException을 슬로우합니다(OP에 표시됨).

ThreadAbortException은 포착할 수 있는 특수 예외이지만 캐치 블록 끝에서 자동으로 다시 상승합니다.

스레드AbortExceptions를 처리해야 하는 코드를 작성하는 방법은 @Mehrdad의 SO에 대한 회신을 참조하십시오. 마지막 블록에서 스레드AbortException을 검색하려면 어떻게 해야 합니까? 런타임을 참조합니다.도우미들.코드 실행보증 정리 방법 및 제한된 실행 영역 사용

---

언급된 Rick Strahl 기사는 유익하며, 댓글도 꼭 읽어보세요.Strahl의 문제는 구체적이었습니다.그는 데이터를 클라이언트(이미지)로 가져온 다음 이미지 제공 속도를 늦추지 않는 히트 추적 데이터베이스 업데이트를 처리하기를 원했으며, 이로 인해 응답 후 작업을 수행하는 데 문제가 생겼습니다.종료가 호출되었습니다.

응답 사용을 고려해 본 적이 없습니다.End(): 프로그램 흐름을 제어합니다.

그러나 응답.End()는 예를 들어 사용자에게 파일을 제공할 때 유용합니다.

응답에 파일을 작성한 경우 파일이 손상될 수 있으므로 응답에 다른 항목을 추가하지 마십시오.

응답을 사용했습니다..NET과 Classic ASP 모두에서 이전의 것을 강제로 종료하려면 종료()합니다.예를 들어, 저는 일정한 로그인 시도 횟수가 있을 때 사용합니다.또는 인증되지 않은 로그인에서 보안 페이지에 액세스하는 경우(대략 예):

    if (userName == "")
    {
        Response.Redirect("......");
        Response.End();
    }
    else
    {
      .....

사용자에게 파일을 제공할 때 플러시를 사용하면 종료로 인해 문제가 발생할 수 있습니다.

나는 응답만 사용했습니다.테스트/디버깅 메커니즘으로 종료()

<snip>
Response.Write("myVariable: " + myVariable.ToString());
Response.End();
<snip>

당신이 올린 글로 미루어 볼 때, Response가 필요하다면 좋지 않은 디자인이라고 생각합니다.끝.

클래식 ASP에서는 일부 아약스 호출에서 3~10초의 TTFB(Time To First Byte)를 사용했는데, 이는 SQL 호출이 더 많은 일반 페이지의 TTFB보다 훨씬 큽니다.

반환된 Ajax는 페이지에 삽입할 HTML의 세그먼트입니다.

TTFB가 렌더 시간보다 몇 초 더 깁니다.

렌더 뒤에 response.end를 추가하면 TTFB가 크게 줄었습니다.

"</body></html>"를 내보내도 동일한 효과를 얻을 수 있지만, json 또는 xml을 출력할 때는 이 작업이 작동하지 않을 수 있습니다. 여기서 response.end가 필요합니다.

언급URL : https://stackoverflow.com/questions/1087777/is-response-end-considered-harmful