As a script in an ASP page is processed, any text or graphics not enclosed within ASP delimiters or <SCRIPT> tags is simply returned to the browser. You can also explicitly send content to the browser by using the Response object.
To send content to the browser from within ASP delimiters or from a procedure, use the Write method of the Response object. For example, the following statement sends a different greeting to the user depending on whether the user has visited the page before:
<%
If blnFirstTime Then
Response.Write "<H3 ALIGN=CENTER>Welcome to the Overview Page.</H3>"
Else
Response.Write "<H3 ALIGN=CENTER>Welcome Back to the Overview Page.</H3>"
End If
%>
Outside of a procedure, you do not have to use Response.Write to send content back to the user. Content that is not within scripting delimiters is sent directly to the browser, which formats and displays this content accordingly. For example, the following script produces the same output as the previous script:
<H3 ALIGN=CENTER> <% If blnFirstTime Then %> Welcome to the Overview Page. <% Else %> Welcome Back to the Overview Page. <% End If %> </H3>
Intersperse script commands and HTML when you just need to return output once or when it is more convenient to add statements to existing HTML text. Use Response.Write when you do not want to break up a statement with delimiters or when you want to build the string that is returned to the browser. For example, you could construct a string of text that builds a table row with values sent by an HTML form:
Response.Write "<TR><TD>" & Request.Form("FirstName") _
& "</TD><TD>" & Request.Form("LastName") & "</TD></TR>"
Request.Form returns the values sent from an HTML form (see Processing User Input).
Note The ampersand character (&) is the string-concatenation character for VBScript. The underscore (_) is the VBScript line-continuation character.
When the Web server returns a file to a browser, it tells the browser what type of content is contained in the file. This enables the browser to determine whether it can display the file itself or whether it has to call another application. For example, if the Web server returns a Microsoft Excel worksheet, the browser must be able to start a copy of Microsoft Excel to display the page. The Web server recognizes file types by mapping the file name extension to a list of MIME (Multipurpose Internet Mail Extensions) types. For example, to start Microsoft Excel, the browser needs to recognize the application/vnd.ms-excel MIME type.
You can use the ContentType property of the Response object to set the HTTP content type string for the content you send to a user. For example, the following command sets the content type for channel definitions:
<% Response.ContentType = "application/x-cdf" %>
For more information about channels, see Creating Dynamic Channels in this topic.
Other common content types are text/plain (for content returned as text instead of interpreted HTML statements), image/gif (for GIF images), image/jpeg (for JPEG images), video/quicktime (for movies in the Apple QuickTime® format), and text/xml (for XML documents). In addition, a Web server or Web browser may support custom MIME types. To see the content types already defined by your Microsoft Web server, use the Internet Information Services snap-in, to open the property sheets for your Web site, click the HTTP Headers tab, and then click the File Types tab. These file types may be used as a reference when you choose to manually set the content type with ASP.
Instead of sending content to a user, you can redirect the browser to another URL with the Redirect method. For example, if you want to make sure users have entered your application from a home page so that they receive a customer ID, you can check to see if they have a customer ID; if they do not, you can redirect them to the home page.
<%
If Session("CustomerID") = "" Then
Response.Redirect "Register.asp"
End If
%>
server-side scripts which are processed before any content is sent to the user are said to be buffered. ASP enables you to turn buffering on or off, and this configuration can greatly affect the behavior of the Redirect method. Specifically, if you have buffering turned off, then you must redirect the browser before your page's HTTP headers are returned to the browser.
Place the Response.Redirect statement at the top of the page, before any text or <HTML> tags, to ensure that nothing has been returned to the browser. If you use Response.Redirect after content or headers have been returned to the browser, you will see an error message. Also note that Response.Redirect does not need to be followed by Response.End.
If you want to use Response.Redirect from the middle of a page, use it along with the Response.Buffer property, as explained in the Buffering Content section in this topic.
Using Response.Redirect to redirect a browser requires a round-trip, meaning that the server sends an HTTP response to the browser indicating the location of the new URL. The browser automatically leaves the server's request queue and sends a new HTTP request for this URL. The server then adds this request to the request queue along with other client's requests that arrived in the meantime. For a busy Web site, round-trips can waste bandwidth and reduce server performance—especially when the browser is redirected to a file located on the same sever.
You can use the Server.Transfer method to transfer from one .asp file to another file located on the same server instead of the Response.Redirect method. With Server.Transfer you can directly transfer requests for .asp files without ever leaving the server request queue, thus eliminating costly round-trips.
For example, the following script demonstrates how you could use Server.Transfer to jump between the pages of an application depending on state information:
<%
If Session("blnSaleCompleted") Then
Server.Transfer("/Order/ThankYou.asp")
Else
Server.Transfer("/Order/MoreInfo.asp")
End if
%>
Server.Transfer sends requests from one executing .asp file to another file. During a transfer, the originally requested .asp file immediately terminates execution without clearing the output buffer (for more information, see the Buffering Content section). Request information is then made available to the destination file when it begins execution. During execution, this file has access to the same set of intrinsic objects (Request, Response, Server, Session, and Application) as the originally requested file.
You can also use Server.Transfer to transfer between .asp files located in different applications. However, when you transfer to an .asp file located in another application, the file will behave as if it was part of the application that initiated the transfer (that is, the file has access only to variables scoped for the initiating application, not for the application where the file actually resides). For example, if you transfer from a file located in the Sales Application to a file located in the Personnel Application, then the Sales Application effectively borrows this file from the Personnel Application and runs it as if it were part of the Sales Application.
ASP also provides the Server.Execute command that you can use to transfer to a file, execute its content, and then return to the file that initiated the transfer. If you are familiar with VBScript, it will help you to think of Server.Execute as analogous to a procedure call, except that instead of executing a procedure, you are executing an entire .asp file.
For example, the following script demonstrates how you could use Server.Execute to do dynamic inclusion of .asp files:
<%
.
.
.
If blnUseDHTML Then
Server.Execute("DHTML.asp")
Else
Server.Execute("HTML.asp")
End If
.
.
.
%>
As long as the destination file belongs to an application on the same server, the originating application will transfer to this file, execute its contents, and then resume executing the file that initiated the transfer. Just as with Server.Transfer, an executed .asp file behaves as if it were part of the originating application. Server.Execute, however, will not work across servers. For more information, see Server.Execute.
By default, the Web server processes all script commands on a page before any content is sent to the user. This process is known as buffering. You can use the Buffer property of the Response object to disable buffering, so that the Web server returns HTML and the results of scripts as it processes a page.
The advantage of buffering your .asp files is that you can abort sending a Web page if, for example, the script processing does not proceed correctly or if a user does not have appropriate security credentials. Instead, you can transfer the user to another page using Server.Transfer, or clear the buffer (using the the Clear method of the Response object) to send different content to the user. Depending on your application, you may want to use the Clear method before transferring. The following example uses both of these methods:
<HTML>
<BODY>
.
.
.
<%
If Request("CustomerStatus") = "" Then
Response.Clear
Server.Transfer("/CustomerInfo/Register.asp")
Else
Response.Write "Welcome back " & Request("FirstName") & "!"
.
.
.
End If
%>
</BODY>
</HTML>
You could also use Response.Buffer to prevent the Web server from returning the HTTP header before a script can modify the header. Certain properties and methods, such as Response.Expires and Response.Redirect, modify the HTTP header.
If the Buffer property in a script is set to TRUE without also calling the Flush method to immediately send buffered content to the browser, the server will maintain Keep-Alive requests made by the client. The benefit of writing scripts in this manner is that server performance is improved because the server does not have to create a new connection for each client request (assuming that the server, client, and any proxy servers all support Keep-Alive requests). However, a potential drawback to this approach is that buffering prevents the server's response from being sent to the user until the server has finished processing the entire script. For long or complicated scripts, users could experience long wait times before seeing the page.
Buffering is turned on by default for ASP applications. You can use the Internet Information Services snap-in, to turn off buffering for an entire ASP application.
Your application may be sending pages to a client through a proxy server. A proxy server acts on behalf of client browsers to request pages from Web sites. The proxy server caches HTML pages so that repeated requests for the same page can be returned quickly and efficiently to browsers. Having the proxy server process requests and cache pages reduces the load on the network and on the Web server.
Although caching works well for many HTML pages, it often does not work well for ASP pages that contain frequently updated information. For example, pages that report stock market prices or display inventory for a high-volume business must provide timely information. Information that is even one hour old might not be accurate enough. If your application returns personalized information, such as a custom home page, you want to ensure that no user sees another user's personal information.
By default, ASP instructs proxy servers not to cache the ASP page itself (although images, image maps, applets, and other items referenced from the page are cached). You can allow caching for certain pages by using the Response.CacheControl property to set the Cache-Control HTTP header field. The default value of Response.CacheControl is the string "Private", which prevents proxy servers from caching the page. To allow caching, set the Cache-Control header field to Public:
<% Response.CacheControl = "Public" %>
Because HTTP headers must be sent to the browser or proxy before any page content is sent, either put the Response.CacheControl property before any HTML tags or, if you have disabled buffering, use Response.Buffer to buffer the page.
The Cache-Control header field is part of the HTTP 1.1 specification. ASP pages are not cached on proxy servers that support only HTTP 1.0 because no Expires header field is sent.
Each browser version has its own rules for determining whether to cache pages. To prevent a browser from caching ASP pages, use Response.Expires to set the Expires header:
<% Response.Expires = 0 %>
A value of 0 forces cached pages to expire immediately. Because HTTP headers must be sent to the browser before any page content is sent, either put the Response.Expires property before any HTML tags or buffer the page.
A channel is a Web technology available with Microsoft Internet Explorer 4.0, or later, that you can use to automatically deliver new or updated Web content to users. The channel schedules the user's computer to periodically connect to a server and retrieve updated information. (This retrieval process is commonly referred to as client pull because information is "pulled" in, or gathered, from the server.) When new information is made available at a particular Web site, the content is downloaded to the browser cache for offline viewing. Clever use of channels for distributing Web based information (especially on intranets) can help to centralize information as well as reduce server traffic. For more information about channels, visit the Microsoft Internet Explorer Web site, at http://www.microsoft.com/windows/ie/.
Using ASP, you can write scripts that dynamically create channels by generating a channel definition file. An XML-based channel definition file (.cdf) describes the organization and update schedule of a channel's contents. Commands in the .cdf file use syntax similar to HTML tags, so they are easy to learn and to generate from a script. When you write a server-side script to create a channel definition file, give the file a .cdx extension. When ASP reads a file with a .cdx extension, it automatically sends the application/x-cdf content type, which tells the browser to interpret the bytes as channel definitions. If you do not use the .cdx extension, your script must manually set the content type to application/x-cdf by using Response.ContentType.
Here is an example of how you might use channels. The following HTML form asks the user to select channels. When submitted, the form calls a script in a .cdx file to create the channel definitions.
<P> Choose the channels you want. </P> <FORM METHOD="POST" ACTION="Chan.cdx"> <P><INPUT TYPE=CHECKBOX NAME=Movies> Movies <P><INPUT TYPE=CHECKBOX NAME=Sports> Sports <P><INPUT TYPE="SUBMIT" VALUE="SUBMIT"> </FORM>
The script in Chan.cdx builds the channel definitions based on the form values submitted with the request.
<% If Request.Form("Movies") <> "" Then %>
<CHANNEL>
channel definition statements for the movie pages
</CHANNEL>
<% End If %>
<% If Request.Form("Sports") <> "" Then %>
<CHANNEL>
channel definition statements for the sports pages
</CHANNEL>
<% End If %>
Distributed Authoring and Versioning (WebDAV), a powerful extension of the HTTP 1.1 protocol, exposes Web file storage media—such as a local file system—over an HTTP connection. WebDAV holds great promise for making the Web into seamless, collaborative authoring environment. With the IIS 5.0 implementation of WebDAV, you can enable remote authors to create, delete, move, search, or apply attributes to files and directories on your Web server.