Server.Transfer is limited?

I'm working at ASP.NET Web Application project and I created a handler, that obviously implement an IHttpHandler Interface, for process and generate a binary file to force a download it.

After config the Web.Config file, the request for "*.abc" file extension will be now intercepted for this handler. But, there is a big problem here, because I'm using the Server.Transfer method, so I cannot send a handler instance for overload of this method or call the "virtual path" directly, like "Page.abc". You can confirm this information decompiling the Transfer method using the Reflector tool:

[ --- Supress --- ]
else if (!(handler is Page))
{
   error = new HttpException(0x194, string.Empty);
}
[ --- Supress --- ]
if (error != null)
{
   [ --- Supress --- ]
   throw new HttpException(SR.GetString("Error_executing_child_request_for_handler",
      new object[] { handler.GetType().ToString() }), error);
}

Independently of Transfer method overload that you use, the error message is the same: "Error executing child request for [handler | Page.abc].". So, the reason why I cannot use the Response.Redirect is that I need to send parameters through Context.Items collection for security intentions.

The temporary solution is to inherit the Page class instead implements IHttpHandler Interface in my handler, but I believe that "solution" isn't elegant.

Comments

# re: Server.Transfer is limited?

Wednesday, July 26, 2006 4:20 PM by Raj

What about using Response.Redirect with your parameters if any in Session?

# re: Server.Transfer is limited?

Wednesday, July 26, 2006 10:00 PM by israel aece

Hello Raj,

Thanks for your feedback. Yeah, the Session would work correctly, but my application will be access for many people, so the Session will degrades performance.

Best Regards,

# re: Server.Transfer is limited?

Wednesday, July 26, 2006 11:46 PM by Gabriel Lozano-Morán

I don't know the exact requirements but why don't you use a HttpModule instead of a HttpHandler?

# re: Server.Transfer is limited?

Thursday, July 27, 2006 8:26 PM by Israel Aece

Hello Gabriel,

Is a alternative too, but I don't understand why the Transfer method overload don't work with a custom handler. :(

# re: Server.Transfer is limited?

Saturday, July 29, 2006 5:27 AM by Gabriel Lozano-Morán

I could help if it was clear what the exact requirements are. For example do you even need a Server.Transfer? Maybe you started out wrong from the root and there is where the problem is.

# re: Server.Transfer is limited?

Sunday, July 30, 2006 10:58 AM by Israel Aece

Hello Gabriel,

I've a handler (IHttpHandler) where I do a binary file and force the download (txt file) of it. So, I thought that a overload of Transfer method would support the instance of my handler.

# re: Server.Transfer is limited?

Monday, July 31, 2006 12:20 PM by Gabriel Lozano-Morán

Why don't you create a Http Handler for the .abc files and map the .abc extension to that Http handler in IIS? Then it will be automatically handled by the Http Handler. You can e-mail me if you want some help with anything.

gabriel [at] pointerx [dot] net

# re: Server.Transfer is limited?

Tuesday, January 02, 2007 2:49 PM by Marco von Frieling

I've exactly the same problem: Creating binary files from the inputs of the transferring Page. The type of input/data is related to tax, National Insurance etc. and should therefore transferred to the handler directly on the server.

Any idea?

# re: Server.Transfer is limited?

Thursday, January 10, 2008 8:02 AM by sudheer

what are the reasons like asp.net server was overloaded,

so, can you please explan me why it happens

what are the reasons please let me know

# re: Server.Transfer is limited?

Saturday, May 03, 2008 3:28 PM by $tealth

Well clearly from that reflector dump the Server.Transfer method needs a little re-coding to work the way it should and not just for Page types.

I read somewhere a tech at Microsoft said this was a design decision to prevent an endless recursive operation resulting in stack overflow...crap! Why?, well there's nothing to stop that happening if you used Server.Transfer in a Page that transfered back to itself, so not a good reason, just a cock up if you wrote code that got itself in that sort of mess.

I overcame this problem by chaining method calls together, like the following pseudocode illustrates:

class A : IHttpHandler {

public void ProcessRequest(HttpContext context) {

 if (context.Request["type"]=="b") {

  IHttpHandler b = new B();

  b.ProcessRequest(context);

 }

}

}

class B : IHttpHandler {

public void ProcessRequest(HttpContext context) {

 Render response...

}

}

Not elegant either, but until Server.Transfer gets fixed at least it stops the round trip overhead incurred with Response.Redirect.