Communicating with Request and Response objects

One of the basic tasks of Active Server Pages is moving information between a Web page and the server. Learn how you can make this happen with the Request and Response objects.

In our previous article, we used ASP to create a basic HTML page containing dynamic content. That simple page introduced several intrinsic objects, including two of the most important ones: the Request and Response objects. Every Web page a visitor sees is first requested by that user. The corresponding response is then interpreted by the browser and displayed on the screen. The Request and Response objects represent the actual request and response that occur between the user and the Web server.

The Request object represents all the data submitted by the user, enclosed in a series of collections. You can think of a collection as an array of data. Some of the items in the array can contain another collection of data, which can sometimes be confusing. The collections are ClientCertificate, Cookies, Form, QueryString, and ServerVariables.

ClientCertificate represents the certificate data passed by the client. The Cookies collection represents the cookie data passed by the user to the server. Form contains any data submitted by the user to the server using an HTML form.

Form data can be submitted using two methods: get and post. The data from a form will show up in the form collection of the Request object only if a form is submitted with the post method. Form data submitted using the get method will appear in the query string.

The QueryString collection contains the data that is present following the question mark in the URL. For instance the URL contains a single QueryString collection item named “parameter1” with a value of 10. The final collection in the Request object, ServerVariables, represents all data from the user request, including other collections like QueryString.

The Response object represents all the data that you send back to the user from the server. While the Request object consists mainly of collections of data, it has more properties related to how the response is generated, as well as a number of methods that generate output. The most common methods are Write (introduced in our first ASP page) and Redirect. The Write method simply takes input and passes it to the output stream destined for the user who requested the current page. The Redirect method sends an HTML 302 (object moved) code in the header of the response, along with the new destination. The 302 instructions are read by the browser, which requests the new destination.

For additional influence over the response being sent to the requesting user, you can use the End, Flush, and Clear methods of the Response object. The End method simply stops processing the current code and sends whatever data is currently in the response buffer. The Flush method allows you to send the current contents of the buffer to the user but continue processing the current page. The Clear method erases any data in the current response.

The Flush and Clear methods require that the Buffer property of the Response object be set to true. This causes the data destined for the user to buffer on the server until the page has completely processed. This setting can improve server performance but can make the page appear slower to the user, since the entire page will be received at once making it “pop” onto the user’s screen instead of rendering piece by piece. (This effect is rarely noticed on high-speed connections, but it can make a considerable difference with slower modem connections.)

Put it to the test
To test the Request and Response objects, we’re going to assemble a test page, which I keep with all of my development projects. This page will display vital information regarding the current request. We’ll use the Response object to output this information. Place this code into a text file named test_servervariables.asp in your wwwroot folder. The entire listing appears in this sidebar.


This page has quite a bit going on, so I’ll try to explain each piece. I purposely used a few different techniques to give you a feel for the flexibility and power that ASP provides.

First, notice the addition of the Response.Buffer = true statement at the top of the page. This should occur before any output to the user, since you can’t buffer something that‘s already left the server. You can also configure this setting globally for the entire server so that you don’t have to place the command on every page.

The first section of the page makes reference to the ScriptEngine properties. I always put this on my test page so that I can quickly determine the status of the environment I am using. The latest version of the scripting engine is 5.5 and contains some useful improvements over previous versions. If you don’t have version 5.5 of the scripting engine, you can download it.

This section also demonstrates a shortcut you can use to output variables within HTML. By using the <%= and %> delimiters, you cause the variable or output to be written directly to the user. This allows you to freely mix ASP code with your HTML but can lead to the spaghetti code problem associated with languages like ASP and JSP.

Another problem with mixing ASP and HTML is performance. Switching repeatedly between HTML and ASP can have a direct effect on the performance of the page. This will be less of a problem with ASP.NET, since those pages will be compiled. Currently, ASP pages are interpreted, so the number of switches between raw HTML and ASP code does affect performance. It’s best to have as few blocks as possible that mix HTML and ASP.

The next section of our test page tries to avoid the switching between ASP and HTML by performing all the output using Response.Write. This section first executes a Response.Flush to send any data in the response buffer to the user. The routine then establishes a loop using the for..each statement, which allows you to loop through a collection very efficiently. The loop then writes to the response each item name in the ServerVariables collection, along with the data contained within that item.

The third section repeats this structure using the QueryString collection of the Request object. If you append some query string parameters to the end of the URL, such as this:

you will see the query string data in the ServerVariables collection as well as the QueryString collection.

Why is this data in both places? Convenience. The QueryString and Form objects were created to allow the programmer easy access to the most common data elements. Without these handy objects, you would have to parse the data from the request yourself. If you call this page, you might also notice the QueryString collection automatically groups the var1 data as a comma-separated string, allowing you to easily separate the data into an array for processing.

The Request and Response objects will appear on almost all of your ASP pages. Become accustomed to using these objects. If you are looking for a good reference on the ASP syntax and commands, try typing the following URL for your local Web server: http://localhost/iishelp. If you installed the Web services, this URL should bring up the online documentation for IIS and ASP. Practice getting data out of the Request object by submitting a form to the page and/or adding query string parameters. As you program more in ASP, the Request and Response objects will become second nature, and you will use their methods extensively.

Suggestions or questions?
Do you have any advice for dealing with Active Server Pages? What ASP topics would you like to see covered? Send us an e-mail with your suggestions and questions.


Editor's Picks