• Choose a category
• All
• Classic-Fiction

void Page_Load(Object sender, EventArgs e)

{

var builder = new StringBuilder();

builder.Append("Response generated before

Execute is called

// Capture child content

var writer = new StringWriter();

Server.Execute("child.aspx", writer);

builder.Append(writer.ToString());

builder.Append("

the call to Execute.");

Label1.Text = builder.ToString();

}

It’s interesting to look at the internal implementation of the Execute method. Both the main and child pages are run by the same HttpApplication object as if they were the same request. What happens within the folds of Execute is a sort of context switch. First, the method obtains an HTTP handler from the application factory to serve the new request. The original handler of the main request is cached and replaced with the new handler. The spawned page inherits the context of the parent; when this step is finished, any modification made to Session or Application is immediately visible to the main page.

The handler switching makes the whole operation extremely fast, as there’s no need to create a new object to serve the request. When the child page returns, the original handler is restored. The execution of the main page continues from the point at which it was stopped, but it uses the context inherited from the child page.

Caution

ASP.NET directly calls the handler indicated by the Execute method without reapplying any authentication and authorization logic. If your security policy requires clients to have proper authorization to access the resource, the application should force reauthorization. You can force reauthorization by using the Response.Redirect method instead of Execute. When Redirect is called, the browser places a new request in the system, which will be authenticated and authorized as usual by IIS and ASP.NET. As an alternative, you can verify whether the user has permission to call the page by defining roles and checking the user’s role before the application calls the Execute method.

Server-Side Redirection

The Transfer method differs from the Execute method in that it terminates the current page after executing the specified page. The new page runs as if it was the originally requested one. The Transfer method has the following overloads:

public void Transfer(String);

public void Transfer(String, Boolean);

public void Transfer(IHttpHandler, Boolean);

The string parameter indicates the destination URL. The Boolean parameter indicates what to do with regard to the QueryString and Form collections. If the parameter is true, the collections are preserved; otherwise, they are cleared and made unavailable to the destination page (which is the recommended approach). You can also directly indicate the HTTP handler to invoke, with the same security issues that were mentioned for Execute.

All the code that might be following the call to Transfer in the main page is never executed. In the end, Transfer is just a page redirect method. However, it is particularly efficient for two reasons. First, no roundtrip to the client is requested, as is the case, for example, with Response.Redirect. Second, the same HttpApplication that was serving the caller request is reused, thus limiting the impact on the ASP.NET infrastructure.

The HttpResponse Object

In ASP.NET, the HTTP response information is encapsulated in the HttpResponse class. An instance of the class is created when the HTTP pipeline is set up to serve the request. The instance is then linked to the HttpContext object associated with the request and exposed via the Response property. The HttpResponse class defines methods and properties to manipulate the text that will be sent to the browser. Although user-defined ASP.NET code never needs to use the HttpResponse constructor, looking at it is still useful to get the gist of the class:

public HttpResponse(TextWriter writer);

As you can see, the constructor takes a writer object, which will then be used to accumulate the response text. All calls made