Other ways to XMLHTTP ActiveX object access to ASP section variables

A couple of months ago, a co-worker came to me and said he had a client JavaScript problem. I had to explain to him that the section variables of the Active Server page (ASP) could not be accessed from the client unless they were passed through a cookie or a hidden input box. But I didn't stop looking for a better way to access the ASP section variables from the client.

When I recently studied how to get information from a server without having to upload and download pages, I read about the contents of the XMLHTTP ActiveX object. Essentially, this object provides a way for Internet Explorer and Web server to communicate and receive a response. It is part of the MSXML dynamic loading library, its current version is 4th edition, and can be downloaded free of charge from Microsoft. It is also important to note that the default version of Microsoft Internet Explorer 5.x,msxml is the 2nd edition.

XMLHTTP Foundation
You can use the XMLHTTP object to execute an ASP on the server, wait for the server to respond, and then act according to the response. This means that with a JavaScript function and a dedicated dynamic server page, it is possible to solve the problem of accessing variables from the client. Does the client need a value for the section variable? No problem! All you have to do is call a small function.

Implementing XMLHTTP Objects
As long as you start trying to implement concepts or features that you haven't tried before, I usually find it easier to break things down into logical pieces. In this case, I start from the server side and the client. With this concept in mind, the server-side Active Server Page I named test.asp looks like this:

<%@ language=vbscript%>
<%
Response.Write
Session (Request.QueryString ("variable"))
%>
The purpose of this server-side code snippet is to return any value of the ASP sector variable associated with the same key in the query string.

Because the request originated from the client and an object is being used, the client section is more detailed. It is necessary to create XMLHTTP objects, set properties of objects, send methods of calling objects, and act on the information returned by the object. Listing A is the JavaScript that performs these tasks.
To further examine the possibility of XMLHTTP, it is necessary to take a step back, because there is a limitation in the use of URLs to send query information from the client to the server side. The maximum URL length is limited to 2,048 bytes. The maximum length of this 2KB also includes this part of the URL's non-query string. To go further, find a better way to send information from the client to the server side.

It took me about 20 minutes to decide how to deliver the information from the client to the server side. I decided to use HTTP. Before you know that I'm crazy but I've been back to God, let me explain. I'm going to pass the message in the HTTP header. Passing information through headers avoids the 2,048-byte limit that can be avoided by using a URL to pass information.

With this in mind, it is now necessary to modify the example of passing information through the URL. This argument is passed by the SetHeader method of the XMLHTTP object, rather than adding parameters to the test.asp URL. Making such a modification results in the client program in Listing B.

On the server side, it is necessary to retrieve the section variable name from the HTTP header instead of the query string of the requesting object. The result is:

<%@ Language=vbscript%>
<%
Response.Write Session (Request.ServerVariables ("Http_test"))
%>
Further
The object I describe here is called XMLHTTP. Note that the first 3 letters of this object are XML. You've seen how to deliver information on both the client and server side, but the XMLHTTP object is designed to allow information to be delivered as XML on both the client and server side. In future articles, I'll explain how to use XML's Simple Object Access Protocol (SOAP) to exchange more complex information.