Hello Paul,
You are welcome.
Thanks for participating the community.
Best regards,
Yanhong Huang
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
!Content-Class: urn:content-classes:message
!From: "Paul de Goede" <
[email protected]>
!Sender: "Paul de Goede" <
[email protected]>
!References: <
[email protected]> <
[email protected]> <1b5701c35ff3
[email protected]> <
[email protected]>
!Subject: Re: Response.Filter not working on Server.Transfer
!Date: Wed, 20 Aug 2003 02:39:05 -0700
!Lines: 202
!Message-ID: <
[email protected]>
!MIME-Version: 1.0
!Content-Type: text/plain;
! charset="iso-8859-1"
!Content-Transfer-Encoding: 7bit
!X-Newsreader: Microsoft CDO for Windows 2000
!X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
!Thread-Index: AcNm/uVFyZ77M9J3SHW8PoVOwsqoSA==
!Newsgroups: microsoft.public.dotnet.framework.aspnet
!Path: cpmsftngxa06.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.aspnet:169456
!NNTP-Posting-Host: TK2MSFTNGXS01 10.40.2.125
!X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
!
!Hi Huang (or is it Yan-Hong?),
!
!Thanks for the link - this is most helpful. I'll download
!it and give it a try.
!
!thanks
!Paul
!
!
!>-----Original Message-----
!>Hello Paul,
!>
!>Thanks very much for posting here.
!>
!>This is a known issue in ASP.NET application and we have
!provided fix for it. Please refer to MSDN KB artile "FIX:
!Calling
!>Server.Transfer Skips Execution of Custom HTTP Filters"
!at
http://support.microsoft.com/?id=814206.
!>
!>To resolve this problem immediately, contact Microsoft
!Product Support Services to obtain the fix. The service
!request for it
!>should be free.
!>
!>The reason their filter is not getting invoked is because
!we execute the httphandler in the CallHandlerExecuteStep.
!From
!>within the context of that step, we call Response.End
!which skips down to the first event wired up to the
!EndRequest event. In
!>the case below, the 15th step. So when we call
!Response.End we short circuit the pipeline and we'll skip
!the
!>CallFilterExecutionStep.
!>
!>+ [0] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [1] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [2] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [3] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [4] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [5] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [6] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [7] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [8] {System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [9]
!{System.Web.HttpApplication.MapHandlerExecutionStep}
!System.Web.HttpApplication.MapHandlerExecutionStep
!>+ [10]
!{System.Web.HttpApplication.AsyncEventExecutionStep}
!System.Web.HttpApplication.AsyncEventExecutionStep
!>+ [11]
!{System.Web.HttpApplication.CallHandlerExecutionStep}
!System.Web.HttpApplication.CallHandlerExecutionStep
!>+ [12]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [13]
!{System.Web.HttpApplication.CallFilterExecutionStep}
!System.Web.HttpApplication.CallFilterExecutionStep
!>+ [14]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [15]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [16]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [17]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [18]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [19]
!{System.Web.HttpApplication.SyncEventExecutionStep}
!System.Web.HttpApplication.SyncEventExecutionStep
!>
!>In ResumeSteps we simply cycle through this array of
!IExecutionSteps. This is what we call the pipeline.
!Because
!>Response.End is called, we skip all the steps after it
!and goto the first step that is associated with the
!EndRequest event. We
!>thus short circuit the pipeline and do not call the
!CallFilterExecutionStep.
!>
!>Basically everything boils down to this:
!>
!>1) With Filter In the Picture: Response.End will short-
!circuit the pipeline and thus will result in the
!CallFilterExecutionStep
!>being skipped. This is because Response.End is executed
!within the context of the CallHandlerExecuteStep. Since
!the
!>response is filtered, it will never get sent to the
!browser.
!>
!>2) With No Filter In the Picture: The response is not
!sent through the Filter and hence skipping the
!CallFilterExecutionStep will
!>not prevent the Response from being sent to the browser.
!>
!>Hope it helps.
!>
!>Best regards,
!>Yanhong Huang
!>Microsoft Online Partner Support
!>
!>Get Secure! -
www.microsoft.com/security
!>This posting is provided "AS IS" with no warranties, and
!confers no rights.
!>
!>--------------------
!>!Content-Class: urn:content-classes:message
!>!From: "Paul de Goede" <
[email protected]>
!>!Sender: "Paul de Goede" <
[email protected]>
!>!References: <
[email protected]>
!<
[email protected]>
!>!Subject: Re: Response.Filter not working on
!Server.Transfer
!>!Date: Mon, 11 Aug 2003 03:28:13 -0700
!>!Lines: 43
!>!Message-ID: <
[email protected]>
!>!MIME-Version: 1.0
!>!Content-Type: text/plain;
!>! charset="iso-8859-1"
!>!Content-Transfer-Encoding: 7bit
!>!X-Newsreader: Microsoft CDO for Windows 2000
!>!X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
!>!Thread-Index: AcNf80TurSgf6XHPQ169Ifp4GmPv9w==
!>!Newsgroups: microsoft.public.dotnet.framework.aspnet
!>!Path: cpmsftngxa06.phx.gbl
!>!Xref: cpmsftngxa06.phx.gbl
!microsoft.public.dotnet.framework.aspnet:166706
!>!NNTP-Posting-Host: TK2MSFTNGXS01 10.40.2.125
!>!X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
!>!
!>!Hi,
!>!
!>!Unfortauntely that means going through all our source
!and
!>!changing all the places where we use server.transfer. On
!>
!>!100000 lines of code that's quite a bit of work.
!>!In addition it also means that we loose the perf. gain
!of
!>!not doing a round-trip to the browser and also more
!>!importantly we make use of server.transfer to pass
!values
!>!between pages sometimes so that will also not work now.
!>!
!>!Server.Transfer is documented to work properly and also
!is
!>!recommended in msdn articles for passing var's between
!>!aspx pages. If it's got limitations which invalidate the
!>!response.filter (or vice versa) then it needs some kind
!of
!>!documentation of caveat.
!>!
!>!Redirect is not a viable work-around to a bug
!>!(limitation?) in the framework.
!>!
!>!Paul
!>!
!>!>-----Original Message-----
!>!>Hi,
!>!>
!>!>1) Use Redirect (preferred).
!>!>2) Server Execute don't cause it, but it got other
!>!limitation.
!>!>
!>!>Natty Gur, CTO
!>!>Dao2Com Ltd.
!>!>34th Elkalay st. Raanana
!>!>Israel , 43000
!>!>Phone Numbers:
!>!>Office: +972-(0)9-7740261
!>!>Fax: +972-(0)9-7740261
!>!>Mobile: +972-(0)58-888377
!>!>
!>!>
!>!>*** Sent via Developersdex
http://www.developersdex.com
!>!***
!>!>Don't just participate in USENET...get rewarded for it!
!>!>.
!>!>
!>!
!>
!>
!>.
!>
!
.