Recommended: ASP tips: Improve the efficiency of using Request collections Accessing an ASP collection to extract a value is a time-consuming and computing resource consuming process. Because this operation contains a series of searches for related sets, this is much slower than accessing a local variable. So if you intend to use a value from the Request collection multiple times in the page
Request and Response are the two most commonly used built-in objects provided by ASP. Between the browser (or other user agent) and the web server, the information exchange that occurs in the request and response can be accessed and managed through two built-in objects in the ASP, called the Request and Response objects.
Almost all the work to be carried out in the ASP page requires access to these two objects. Using these two objects will affect the efficiency and reliability of the page. Of course, their main purpose is to access the value sent back to the server by the user, i.e. obtain from the <FORM> segment of the HTML page or attach it to the URL as a query string, and create appropriate output to return to the user, and they can share many of the same factors. For example, both objects can use cookies stored on the client computer.
Therefore, we divide the content into two independent parts (part of each object), and first start with the information exchange between the client and the server, and then study each object.
The research content is:
· How the client communicates with the server to deliver the web or other resources.
· Details of Request and Response objects, and what they are in common.
· How to access the corresponding value through a form and query string.
· How to read or create cookies and store them on the client's computer.
· What are the variables of the server? How to access and modify HTTP headers.
· Describe changes to other related entries, such as the use of the customer's certificate.
Communication between clients and servers
To save space, the word browser is used in the following content. But it should be remembered that applications that can access web pages are not only browsers, but many special applications download web pages from sites, such as special client programs designed for those who have vision defects or those who have other difficulties using the usual browser. The most obvious example is the robot used by search engines to access sites on the web. Consider these factors comprehensively, including ordinary web browsers, the exact word should be a user agent.
Page request conversation
When a browser makes a page request to a Web site, it obviously has to tell the server which page it is requesting. The first thing to do is to establish a connection to the server through the domain name, and then provide the full path and name of the requested page. Why do you need full path and name? The web is a borderless environment, so it is necessary to create a session to identify each client (how ASP can do this later).
This means that every time the server completes sending the page to the client, the server completely forgets the client. So when the client requests the next page, it is exactly the same as a new visitor. The server cannot remember this customer, and accordingly, it cannot determine which page they requested last time. Because, you cannot use a relative path to provide a page, even if the page contains a relative link, for example:
＜A HREF=http://www.CuoXIncom/Download.asp>Next Page＜/A>
The browser will automatically create a complete new page URL by using the domain and path of the current page; or use the <BASE> element in the <HEAD> section of the page to tell the browser what the URL of all links in a page is. For example:
＜BASE HERF=http://www.CuoXIn.com＞
When pointing the mouse to a link to a page, it can be seen in the browser's status bar. The path to the current page and the current domain or base domain or base path have been combined with the requested page name.
1. Details of customer requests
The combination of the full path and name of the requested page is the only residence of the server when the browser requests the page. The browser request can also include the residence of the browser host and the operating system running by the client. The actual information content will change accordingly with the browser, and only a small number of it can be provided by other applications such as search engine robot. To get a clearer understanding of this information, here is a pair of pages issued from IE 5.0
Download.asp request information:
7/8/99 10:27:16 Sent GET /Store/Download.asp HTTP/1.1
Accept: application/msword, application/vnd.ms-execl, application/vnd.ms-
powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-
comet, */*
Accept-Language: en-us
Encoding: gzip, deflate
Referer: http://wwrox.com/main_menu.asp
Cookie: VisitCount=2&LASTDATE=6/4/99 10:10:13 AM
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Host: 212.250.238.67
Connection: Keep-Alive
From this, it can be seen that the information contains details about the user agent and user connection (such as the default language), as well as a list of types of acceptable files or applications, which are of MIME type, and you will see more later. The browser can accept several image files and multiple Microsoft Office file types. Standard file types such as tesx/html and text/text are not listed in it. */* in the file list means that any type of file can be sent back to the browser, interpreted by the browser or through a plug-in application.
cookie: The cookie contained in the entry is stored on the client's computer and is only valid for this domain. If the request is the result of clicking on the link, instead of directly entering the URL in the browser's address bar, Referer: The entry is displayed, which contains the complete URL of the link page.
Host: The entry contains the IP address or name of the client computer. However, this is not enough to accurately identify the client. Because when they connect through an ISP, the IP addresses are dynamically allocated, or when they connect through a proxy server, the IP addresses are from the proxy rather than from the actual client.
2. Details of server response
In order to respond to the above request and provide the requested page to an anonymous browser (that is, the user does not have to provide a username and access password), the following content is sent from the server to the client:
7/8/99 10:27:16 Received HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Connection: Keep-Alive
Date: Thu, 8 Jul 1999 10:27:16 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 2946
Last-Modified: Thu, 8 Jul 1999 10:27:16 GMT
Cookie: VisitCount=3&LASTDATE=7/8/99 10:27:16 AM
＜HTML＞
… rest of page …
＜/HTML＞
It can be seen that the server explains the software and version it uses to the client. The first line shows that the HTTP protocol is used and the status of the return code. Message 200 OK means that the request was accepted and satisfied. The following information is the details of the page being returned, including the MIME type (Content-Length:), size (byte), the last change time, and the return cookie stored by the client. The other information in the response is the information flow of the page content.
In some cases, the server cannot return a page after responding to a request, perhaps because the page does not exist, or the client does not have the corresponding permissions to access it. We will discuss security issues later. Now, for situations where the request page does not exist (for example, the user entered the wrong URL in the browser's address bar), the returned information starts with:
7/8/99 14:27:16 Received HTTP/1.1 404 Not Found
Server: Microsoft-IIS/5.0
…
Here, the status code and information indicate that the page requested by the client cannot be found. The browser can use this information to display the corresponding information to the user (in this case, in IE 5.0, the server's response information is not displayed, but the corresponding helping error prompt page) or the default page created by the server (dependent on the server's settings). Request and Response objects
The details of being able to apply client requests and server responses from ASP are implemented through the ASP's built-in Request and Response objects.
· Request object: provides scripts with all the information provided by the client when the client requests a page or passes a form. This includes HTTP variables that can indicate the browser and user, cookies stored in the browser under this domain name, any HTML control value attached as a query string to the string after the URL or the page's <FORM> section. Authorized access using Secure Socket Layer (SSL) or other encrypted communication protocols, as well as attributes that help manage connections.
· Response object: Used to access the response information created by the server and sent back to the client. Provides HTTP variables for scripts that indicate the functions of the server and server and information about the content sent back to the browser, as well as any new cookies that will be stored in the browser for this domain. It also provides a range of methods to create output, such as the ubiquitous Response.Write method.
1. Overview of Request object members
a) Collection of Request objects
The Request object provides 5 collections that can be used to access various information requested by the client to the Web server. These collections are as follows:
Collection and description of Request objects
| Collection name | illustrate |
| ClientCertificate | When a client accesses a page or other resource, the numerical set of all fields or entries of the client certificate used to indicate identity to the server, each member is read-only |
| Cookies | According to the user's request, a collection of all cookies issued by the user's system. These cookies are only valid for the corresponding domain, and each member is read-only |
| Form | When the attribute value of METHOD is POST, each member is read-only for all sets of values of HTML control units in the <FORM> section submitted as request. |
| QueryString | Each member is read-only for the value of all HTML control units in <FORM>, depending on the name/value pair after the URL requested by the user or submitted as a request and the METHOD attribute is GET (or its attribute is omitted), or the values of all HTML control units in <FORM> |
| ServerVariables | A collection of HTTP header values issued by the client request and the values of several environment variables of the web server, each member is read-only |
b) Properties of Request object
The unique properties and description of the Request object are shown in the following table. It provides information about the number of bytes requested by the user. It is rarely used in ASP pages. We usually focus on the specified value rather than the entire request string.
| property | illustrate |
| TotlBytes | Read-only, returns the entire number of bytes of the request issued by the client |
c) Methods of Request object
The only method and description of the Request object are shown in the following table, which allows access to the complete content of the user request part passed to the server from a <FORM> segment.
Method and description of Request object
| method | illustrate |
| BinaryRead(count) | When the data is sent to the server as part of the POST request, the count bytes of data is obtained from the client request and a Variant array (or SafeArray) is returned. If the ASP code already references the Request.Form collection, this method cannot be used. At the same time, if the BinaryRead method is used, the Request.Form collection cannot be accessed |
2. Overview of Response object members
a) Collection of Response objects
The Response object has only one collection, as shown in the following table, which sets the value of the cookie you want to place on the client system, which is directly equivalent to the Request.Cookies collection.
Collection and description of Response objects
| Collection name | illustrate |
| Cookies | In the current response, the values of all cookies sent back to the client, this set is write-only |
b) Properties of Response object
The Response object also provides a series of properties that can be read (in most cases) and modified so that the response can be adapted to the request. These are set by the server and we don't need to set them up. It should be noted that when setting certain properties, the syntax used may be different from what is commonly used.
Properties and descriptions of Response objects
| property | illustrate |
| Buuffer=True|False | Read/write, Boolean, indicating whether the output created by an ASP page is stored in the IIS buffer until all server scripts on the current page are processed or the Flush and End methods are called. This property must be set before any output (including HTTP reporting information) is sent to IIS. Therefore, in the .asp file, this setting should be in the first line after the <%@LANGUAGE=…%> statement. ASP 3.0 default buffering is on (True), while in earlier versions it is off (False) |
| CacheControlsetting | Read/write, character type, set this property to Public to allow the proxy server to cache pages. If it is Private, it prohibits the proxy server to cache. |
| Charset=value | Read/write, character type, attach the character set name used in the HTTP Content-Type header created by the server for each response (for example: ISO-LATIN-7) |
| Content Type=MIME-type | Read/write, character type, specify the HTTP content type of the response, and the standard MIME type (such as text/xml or Image/gif). If default, it means that MIME type text/html is used, and the content type tells the browser the type of content expected. |
| Expires minutes | Read/write, numerical type, indicates the length of time the page is valid in minutes. If the user requests the same page before the expiration of the validity period, the content in the display buffer will be read directly. After this valid period, the page will no longer be retained in the private (user) or public (proxy) buffer. |
| Expires Absolute #date [time]# | Read/write, date/time type, indicating the absolute date and time when a page expires and is no longer valid |
| IsClientConnected | Read-only, Boolean, returns the status flag of whether the client is still connected and downloaded. Before the current page has been executed, if a client is transferred to another page, this flag can be used to abort the processing (using the Response.End method) |
| PICS (PICS-Label-string) | Write only, character type, create a PICS header to define the vocabulary level in the page content, such as violence, sex, bad language, etc. |
| Status=Code message | Read/write, character type, status values and information indicating whether the HTTP header sent back to the client's response indicates whether the error or page processing is successful. For example 200 OK and 404 Not Found |
c) Methods of Response object
The Response object provides a series of methods, as shown in the following table, allowing direct processing of page content created to be returned to the client.
Methods and descriptions of Response objects
| method | illustrate |
| AddHeader(name,content) | Create a custom HTTP header by using name and Content values and add it to the response. An existing header with the same name cannot be replaced. Once a header has been added, it cannot be deleted. This method must be used before any page content (i.e. text and HTML) is sent to the client |
| AppendToLog(string) | When using the W3C Extended Log File Format file format, add an entry to the log file of the web server requested by the user. At least require URL Stem to be selected in the Extended Properties page of the site containing the page |
| BinaryWrite(safeArray) | Write a Variant-type SafeArray in the current HTTP output stream without any character conversion. It is very useful for writing non-string information, such as binary data requested by a custom application or binary bytes that make up an image file |
| Clear() | When Response.Buffer is True, delete the existing buffered page content from the IIS response buffer. But the header of the HTTP response can be used to abandon partially completed pages |
| End() | Let the ASP end the script for processing the page and return the currently created content, and then abandon any further processing of the page |
| Flush() | Send all the current buffered pages in the IIS buffer to the client. When Response.Buffer is True, it can be used to send part of the content of a larger page to individual users |
| Redirect(url) | By sending a 302 Object MovedHTTP header in the response, the browser instructs the page of the corresponding address according to the string url |
| Write(string) | Write specified characters in the current HTTP response stream and IIS buffer to make it part of the return page |
Share: Full contact with stored procedure applications in ASP development There are many articles on ASP and Stored Procedures, but I doubt that the authors have actually practiced it. I read a lot of relevant information when I was in the beginning and found that many of the methods provided were not the case in practice. For simple applications, these data