Server.Transfer and IHttpModule problem

[Richard]

I've developed a small ASPX template framework (based on Chun Li's
article on CodeProject:
http://www.codeproject.com/aspnet/headerfooter.asp#xx849313xx) which
uses a IHttpModule to apply usercontrols (e.g. header and footer) on
pages.
The module determines if templates should be added to the page using
Page.Request.Path. It matches the current adress to settings found in a
configuration-file...

It works like a charm except for one little problem with
HttpServerUtility.Transfer.
Server.Transfer doesn't change the path-related properties needed.

I realize that the Path-property might not be the correct property to
use in this particular case.
The documentation states that the HttpRequest.CurrentExecutionFilePath
property should change when Server.Transfer is called.
I've verified that it does on the target/child page by outputting the
variable.

The problem lies in the fact that the property hasn't changed in the
IHttpModule.
I'm using the HttpApplication.Context which is of type
System.Web.UI.Page to attach an eventhandler to the Page.Init-event.

Is this a bug or am I missing something here!?

I want a non-intrusive way to add templates to any page. This means
that the page can't know anything about templates, such as utilizing
RewritePath which might avoid the problem.

Regards,
Richard

 

[S. Justin Gengo [MCP]]

Richard,

Server.Transfer executes the page being requested without going back to the
client. It's a more direct, faster way to send a client a page. Here's a
comparison:

If a client requests page1 of your website and then posts back and you
execute a Response.Redirect to page2 the client browser is sent new code
that tells it to go to page2. Therefore in this scenario your handler gets
the correct page because the client has requested it.

If a client requests page1 of your web then posts back and you execute a
Server.Transfer to page2 the client browser is not contacted at all. Instead
the web server sends page2 to the client as if page2 is page1. The client
doesn't even know it's on a different page.

The context object is a common way to pass values from one page to another
when using Server.Transfer. Just before the transfer a value may be added to
the context object: Context.Item.Add("[Key]", [Value as Object]). Then on
the new page the same context object may be accessed via its key:
Context.Item("[Key]"). Perhaps you could set a context object when utilizing
Server.Transfer in order to set your template. I don't know for certain if a
context item will be accesible to your module... But it's worth a try.

--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

www.aboutfortunate.com

"Out of chaos comes order."
Nietzsche

 

[Richard]

Thank you for your reply!

I'm aware of the differences between Response.Redirect and
Server.Transfer and how they work, unfortunately some of the pages I'm
applying this solution to needs to be able to work with
Server.Transfer.

Using the Context-object works fine but that would make the pages aware
of the template-framework which is what I want to avoid.

The question is why the CurrentExecutionFilePath remains the same
during the call to the IHttpModule but has changed when the child page
receives the call.
Even though I've attached eventhandlers to the exact same event
(Page.Init) and most likely the same Page-object the property differs.

If you have access to the source of the Server.Transfer-method you will
see that the method is responsible for changing the property on the
HttpRequest-object of the current page.

/ Richard

 

[S. Justin Gengo [MCP]]

Richard,

My belief is that when Server.Transfer is called it bypasses the IHttpModule
completely and just loads up the child page.

--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

www.aboutfortunate.com

"Out of chaos comes order."
Nietzsche

 

[Richard]

That was my initial belief too but the IHttpModule is called every
time.

I simply accessed the Page.Response (from inside the IHttpModule) to
output a new GUID every time the IHttpModule was called to see if it
did.

/ Richard

 

[S. Justin Gengo [MCP]]

Hmmmm,

Well, then, that's very strange. I'm afraid I don't have an answer for you.
I'll look around and see if I find anything. But I wouldn't have expected
the behaviour you're seeing based on this information.

--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

www.aboutfortunate.com

"Out of chaos comes order."
Nietzsche