Communication between the client and the server

Server | client

The previous chapter describes some of the basic issues with installation settings and the use of a S p, as well as the built-in objects it provides. This chapter will further examine the two most commonly used objects. Between browsers (or other user agents) and our B servers, the exchange of information that occurs in requests and responses can be accessed and managed through two built-in objects in the ASP, which are called request and response objects.
Almost all of the work you want to do in an ASP page is to access both objects, and the way you use them affects the efficiency and reliability of your pages. Their main purpose, of course, is to access the values that users send back to the server, either from the < FORM > section of the HTML page, or as a query string, and create the appropriate output to return to the user, and they can share many of the same factors. For example, two objects can use cookies that are stored on the client computer.
Therefore, we divide this chapter into two separate sections (each part of the object) and start with the information exchange between the client and the server, and then examine each of the objects. This will further help to understand the relationship between them and their importance.
Therefore, the contents of this study are:
How the client communicates with the server to pass a Web page or other resource.
The details of the request and response objects, and the similarities between them.
How to access the corresponding value through a form and query string.
How to read or create cookies and store them on the client computer.
What are the server variables? How to access and modify the HTTP header.
Describe changes to other related items, such as the use of the customer's certificate.
First look at the communication between the client browser (or "User Agent") and the ASP's Web server.
When a browser or other user agent accesses a Web site Request page, a conversation is generated between the client server and the Web server, and we will examine this issue carefully, because understanding this issue helps to master the basics of using the ASP's request and response objects. In order to further understand the ASP's more knowledge.
To save space, use the word "browser" (browser) in this chapter and later in this book. But keep in mind that applications that can access Web pages are not just browsers, there are many special applications that download Web pages from sites, such as special client programs designed for visually impaired users or other difficulties with the usual browsers. The most obvious example is the robot that search engines use to access sites on the web. Consider these factors comprehensively, including a common web browser, and the exact words should be the user agent.
Dialog for page requests
When a browser presents a page request to our B site, it is clear that the server must be told which page it is requesting. The first thing to do is to establish a connection with the server through the domain name, and then provide the full path and name of the requested page. Why do I need full path and name? The web is a borderless environment, so you must create a session to identify each customer (how the ASP does this in the next chapter).
This means that every time the server completes sending a page to the customer, the server completely forgets about the customer. Therefore, when the customer requests the next page, it is exactly the same as a new visitor. The server is unable to remember the customer and, accordingly, cannot determine which page they last requested. Therefore, you cannot use a relative path to provide a page
Face, even if the page contains a relative link is not good, for example:

The browser will automatically create a complete URL for the new page by using the current page's domain and path, or by using the < Base > element in the page < head > section to tell the browser what the base URL is for all links in a page. For example:

When you point the mouse at a link to a page, you can see the situation shown in Figure 2-1 in the browser's status bar. The path to the current page and the current or base domain name are already combined with the requested page name.

1. Details of Customer requests
A combination of the full path and name of the requested page is the only information that the browser sends to the server when it requests the page. The browser's request can also contain information hosted by the browser and the operating system that the client is running. The actual content of the information will change with the browser, and only a few can be provided by other applications such as search engine robot. To get a clearer picture of this information, here is a request message from IE 5.0 for the page http://www.wrox.com/Store/Download.asp:

As you can see, the information contains details about the user agent and user connections (such as the default language), as well as a list of the types of files or applications that can be accepted, all of which are MIME types and will be met later. Browsers can accept several image files and a variety of Microsoft Office file types. "Standard" file types, such as text/html and Text/text, are not listed therein. The */* in the file list indicates that any type of file can be sent back to the browser, interpreted by the browser, or explained by a plug-in (plug-in) application.
Cookie: The entry contains a cookie that is stored on the client computer and is valid only for that domain. If the request is the result of clicking on the link instead of entering the URL directly in the browser's address bar, Referer: The entry is displayed and contains the full URL of the linked page.
Host: Entry contains the IP address or name of the client computer. However, this is not sufficient to accurately identify the client. Because the IP address is dynamically assigned when they are connected through the ISP, or when connected through a proxy server, the IP address is the agent rather than the actual client.
2. Detail information of server response
To respond to the above request, and to provide the requested page for the Anonymous browser (that is, the user does not have to provide a username and access password), the following is sent from the server to the client:

You can see the server to the client to explain their own software and version, the first line indicates that the HTTP protocol used, and return code status. Information "OK" indicates that the request was accepted and satisfied. The following information is the details of the returned page, including the MIME type (content-length:), size (bytes), the time of the most recent change, and the cookie that returns the client store. Other information in the response is the flow of content in the page.
In some cases, the server cannot return a page after responding to a request, perhaps because the page does not exist or the customer does not have the appropriate permissions to access it. We will discuss security issues in subsequent chapters of this book. Now, for situations where the request page does not exist (for example, the user has entered the wrong URL in the browser's address bar), the information returned begins with:

Here, the status code and information indicate that the page requested by the customer cannot be found. The browser can use this information to display to the user the appropriate information (this situation in IE 5.0 does not display the server's response information, and display the appropriate "Help" Error prompt page), you can also display the server to create the default page (depending on the server's settings).
Now that we've seen some of the details of the client-server interaction, here's how ASP object request and response can convert these to the appropriate values.