Response.Filter not working on Server.Transfer

[Paul de Goede]

I set the Response.Filter in my aspnet application but I
have noticed that if you do a Server.Transfer that the
filter doesn't get called. And in actual fact the response
is mostly empty. It seems that only scripts get rendered.

I have seen this mentioned on this newsgroup before but
with no resolution. Can anyone give any insight into this
problem. Is there a work around? Manually push the
Reponse.OutputStream through your filter after you've
rendered the page?

Any ideas?

Paul

[Paul de Goede]

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: [phone]
Fax: [phone]
Mobile: [phone]
*** Sent via Developersdex http://www.developersdex.com ***Don't just participate in USENET...get rewarded for it!
.

[Natty Gur]

YOU ARE absolutely RIGHT.

But as far as I know there aren’t any other solutions. I'm stuck with
the same problem and I’ll be happy to hear other solutions.

By the way, I’m not working in MS, Yet :-).

Natty Gur, CTO
Dao2Com Ltd.
34th Elkalay st. Raanana
Israel , 43000
Phone Numbers:
Office: [phone]
Fax: [phone]
Mobile: [phone]
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Yan-Hong Huang[MSFT]]

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.MapHandlerExecutionSte p} System.Web.HttpApplication.MapHandlerExecutionStep
+ [10] {System.Web.HttpApplication.AsyncEventExecutionSte p} System.Web.HttpApplication.AsyncEventExecutionStep
+ [11] {System.Web.HttpApplication.CallHandlerExecutionSt ep} System.Web.HttpApplication.CallHandlerExecutionSte p
+ [12] {System.Web.HttpApplication.SyncEventExecutionStep } System.Web.HttpApplication.SyncEventExecutionStep
+ [13] {System.Web.HttpApplication.CallFilterExecutionSte p} 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" <pa**@nospam.kineticmds.com>
!Sender: "Paul de Goede" <pa**@nospam.kineticmds.com>
!References: <02****************************@phx.gbl> <Ou**************@TK2MSFTNGP09.phx.gbl>
!Subject: Re: Response.Filter not working on Server.Transfer
!Date: Mon, 11 Aug 2003 03:28:13 -0700
!Lines: 43
!Message-ID: <1b****************************@phx.gbl>
!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: [phone]
!>Fax: [phone]
!>Mobile: [phone]
!>
!>
!>*** Sent via Developersdex http://www.developersdex.com
!***
!>Don't just participate in USENET...get rewarded for it!
!>.
!>
!

[Natty Gur]

Thanks !!!

Natty Gur, CTO
Dao2Com Ltd.
34th Elkalay st. Raanana
Israel , 43000
Phone Numbers:
Office: [phone]
Fax: [phone]
Mobile: [phone]
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Yan-Hong Huang[MSFT]]

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" <pa**@nospam.kineticmds.com>
!Sender: "Paul de Goede" <pa**@nospam.kineticmds.com>
!References: <02****************************@phx.gbl> <Ou**************@TK2MSFTNGP09.phx.gbl> <1b5701c35ff3
$4****************@phx.gbl> <rI*************@cpmsftngxa06.phx.gbl>
!Subject: Re: Response.Filter not working on Server.Transfer
!Date: Wed, 20 Aug 2003 02:39:05 -0700
!Lines: 202
!Message-ID: <27****************************@phx.gbl>
!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.MapHandlerExecutionSt ep}
!System.Web.HttpApplication.MapHandlerExecutionSte p
!>+ [10]
!{System.Web.HttpApplication.AsyncEventExecutionSt ep}
!System.Web.HttpApplication.AsyncEventExecutionSte p
!>+ [11]
!{System.Web.HttpApplication.CallHandlerExecutionS tep}
!System.Web.HttpApplication.CallHandlerExecutionSt ep
!>+ [12]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [13]
!{System.Web.HttpApplication.CallFilterExecutionSt ep}
!System.Web.HttpApplication.CallFilterExecutionSte p
!>+ [14]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [15]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [16]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [17]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [18]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!System.Web.HttpApplication.SyncEventExecutionStep
!>+ [19]
!{System.Web.HttpApplication.SyncEventExecutionSte p}
!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" <pa**@nospam.kineticmds.com>
!>!Sender: "Paul de Goede" <pa**@nospam.kineticmds.com>
!>!References: <02****************************@phx.gbl>
!<Ou**************@TK2MSFTNGP09.phx.gbl>
!>!Subject: Re: Response.Filter not working on
!Server.Transfer
!>!Date: Mon, 11 Aug 2003 03:28:13 -0700
!>!Lines: 43
!>!Message-ID: <1b5701c35ff3$4****************@phx.gbl>
!>!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: [phone]
!>!>Fax: [phone]
!>!>Mobile: [phone]
!>!>
!>!>
!>!>*** Sent via Developersdex http://www.developersdex.com
!>!***
!>!>Don't just participate in USENET...get rewarded for it!
!>!>.
!>!>
!>!
!>
!>
!>.
!>
!