ASP.NET 라우팅이 web.config Http 처리기 섹션보다 우선하는 이유는 무엇입니까?

Question

저희 가게는 system.webServer \ handlers 아래 web.config에 정의 된 타사 HTTP 처리기 &을 사용하는 대형 웹 응용 프로그램에 ASP.NET MVC를 통합하고 있습니다. 이 방법으로 HTTP 처리기를 활용하면 응용 프로그램을 다시 컴파일하거나 실제 처리기 페이지를 제품의 각 인스턴스에 대한 웹 범위의 어딘가에 디스크에 두지 않아도되므로 유용했습니다.

global.asax에 명시 적으로 Ignore Routes를 추가하여 런타임에서 web.config에 정의 된 Handler를 존중할 수 있도록해야합니까? 나는 Web.Routing이 이후에 으로 호출 될 것이라고 생각했을 것입니다. system.webServer \ handlers에 정의 된 핸들러가 점검되었습니다 (다른 방법은 아닙니다).

우리는 기능 추가시 web.config에서 Handlers를 추가/삭제할 수있는 모듈 식 디자인을 사용합니다. MVC 라우팅을 도입하면 web.config에 정의 된 모든 가능한 핸들러에 대해 global.asax 파일에 경로 무시를 추가해야합니다.

이 핸들러의 실제 파일은 디스크 상에 존재하지 않습니다. 이것은 가상이며 어셈블리에 포함되어 있습니다. 당신은 당신이 웹에 지정된 HTTP를 핸들러에 대한 경로를 무시 포함해야 System.Web.Routing 사용하는 경우 레코드 그래서

<system.webServer> 
    <handlers> 
      <!-- telerik radcontrols --> 
      <add name="TelerikDialogHandler" verb="*" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Version=2009.1.402.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4"></add> 
    </handlers> 
</system.webServer> 

: 여기에 지금의 Global.asax에 경로를 무시 명시를 요구하는 제 3 자 핸들러의 예 . 구성? 아니면 뭔가 잘못하고있는 것일까 요?

Answer 1

ASP.NET 요청 처리는 ASP.NET이 파이프 라인의 모든 모듈에 HTTP 요청을 전달하는 파이프 라인 모델을 기반으로합니다. 각 모듈은 http 요청을 받고이를 완전히 제어 할 수 있습니다. 요청이 모든 HTTP 모듈을 통과하면 결국 HTTP 처리기에 의해 처리됩니다. HTTP 처리기는 처리를 수행하고 결과는 다시 파이프 라인의 HTTP 모듈을 통과합니다.

내가 생각하기에 가장 좋은 방법은 HttpModule이 이벤트가 발생할 때 요청 객체에서 무언가를 더하거나 뺍니다. HttpHandler가 실제로 요청을 처리하는 프로세서라는 것입니다. ASP.NET 요청 수명주기는 모든 필터이 처리되기 전에 처리이 발생하기 전에 요청에 적용되는 방식으로 설정됩니다.