Java程序辅导
C C++ Java Python Processing编程在线培训 程序编写 软件开发 视频讲解
C C++ Java Python Processing编程在线培训 程序编写 软件开发 视频讲解
Figure 4.5.7: Requesting four objects with HTTP/1.1 and a fourth object with HTTP/1.0 from a second server Figure 4.5.7 illustrates a sample scenario that benefits from HTTP/1.1. The client connects to foo.com and requests the file index.html, which is shown in Code Listing 4.12. This file references two more files, script.js and logo.png, that are both stored on foo.com. These additional files are retrieved with separate HTTP requests. These requests are asynchronous, so the client can do other work while waiting for them. While waiting, the client connects to zoo.com with a request for library.js. Since this is the only file needed from that server, the client uses HTTP/1.0, which closes the socket immediately. Since the requests to foo.com used HTTP/1.1, the client must explicitly send a separate request to close the connection once all files have been received. The asynchronous requests shown in Figure 4.5.7 are common in modern web designs. These applications frequently augment HTML with JavaScript to create a dynamic and interactive web page; for instance, clicking on a button may produce a drop-down box of menu options to appear. In some cases, the JavaScript code may issue asynchronous HTTP requests. In truth, the web browser issues the request, as all client-side software (including JavaScript) runs as part of the browser process. These requests are standard HTTP requests as we have observed, with the exception that the browser uses multiple threads of execution to issue that request and wait for the response while doing other work. When the browser receives the HTTP response, it will invoke a JavaScript callback routine that the script declared ahead of time to be responsible for handling the data. The web page’s URL does not appear to change, but it is possible to observe these requests as they happen. Most popular web browsers include a menu option, typically called something like “Developer Tools,” that can monitor and even modify these requests. To be clear, the use of persistent TCP connections does not change the nature of HTTP as a stateless protocol. Although the TCP connection will remain open from one request to the next, the server does not maintain any local information about the specifics of the previous HTTP request or how it responded. The persistent connection is simply a performance improvement, and each request-response is considered a distinct, unrelated exchange. 4.5.4. Processing HTTP Headers¶ After the HTTP-Version, the remainder of the HTTP response Status-Line provides information to the client about whether or not the request was successful. The status is reported both as a number (Status-Code) and a text description (Reason-Phrase). Table 4.5 describes several of the most common statuses. The Reason-Phrases shown here are used by convention and they have no specific effect on processing the response; a web server could choose to break this convention with arbitrary Reason-Phrases and the response would still be processed identically. Status Reason-Phrase Purpose 200 OK Request was successful 301 Moved Permanently File has been moved to a new location 400 Bad Request The HTTP request had incorrect syntax 401 Unauthorized The request requires user authentication 403 Forbidden Access to the resource is not allowed 404 Not Found No file was found based on Request-URI 500 Internal Server Error The server had an unexpected error or fault 503 Service Unavailable The server is unavailable or not accepting new requests Table 4.5: Common HTTP response status messages and their meanings Some status codes are unrecoverable error messages. For instance, if a client receives 404 or 503 message, either the requested file does not exist or the server is down. There is nothing that the web browser can do to correct those situations, and the browser simply displays an error message. Other codes do allow the browser to respond automatically. If the server responds with a 301 status, the HTTP response should include a Location header that designates the new location; this may be a different URI on the same server, or it might be a full URL because the domain name is different. Web browsers can read this header and re-issue a new HTTP request based on this new location. As another example, if the server responds with a 401 status, the response must include a WWW-Authenticate header with a challenge. The browser may re-issue the request with an added Authorization header field that stores credentials to respond to the challenge. Although writing HTTP headers—as shown in Code Listing 4.11—is straightforward, reading them at the other end can be a challenge if not handled properly. The difficulty arises from the fact that header sizes vary, so the receiver does not know how many bytes to request from the socket at a time. To address this challenge, both clients and servers typically impose a maximum header size of 8 KB by convention. The initial read from the socket requests this much data. If a complete header is not found in this space, then the connection is terminated as invalid by clients; servers that receive such invalid headers return Status 413 to indicate Entity Too Large. A complete header must end with a blank line, creating the four-byte sequence "\r\n\r\n". Code Listing 4.13 demonstrates how to perform this check by looking for this string. If it is found, the second '\r' is replaced with the null-byte '\0' to convert buffer to a complete string of the header, with each header line ending in CRLF. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 /* Code Listing 4.13:
Checking for a complete HTTP response header
*/
#define HEADER_MAX 8192
/* Allocate a buffer to handle initial responses up to 8 KB */
char *buffer = calloc (HEADER_MAX + 1, sizeof (char));
ssize_t bytes = read (socketfd, buffer, HEADER_MAX);
assert (bytes > 0);
/* Look for the end-of-header (eoh) CRLF CRLF substring; if
not found, then the header size is too large */
char *eoh = strnstr (buffer, "\r\n\r\n", HEADER_MAX);
if (eoh == NULL)
{
fprintf (stderr, "Header exceeds 8 KB maximum\n");
close (socketfd);
return EXIT_FAILURE;
}
/* Replace the blank line of CRLF CRLF with \0 to split the
header and body */
eoh[2] = '\0';
Once the header and body have been split, processing the header involves repeatedly breaking it at the CRLF locations. Code Listing 4.14 extends Code Listing 4.13 to demonstrate this processing, printing all header lines but looking specifically for the Content-Length header. Since Code Listing 4.13 ended by replacing the blank line of CRLF CRLF with the null byte, line 25 will set eol to NULL after the last header line is processed. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 /* Code Listing 4.14:
Extending Code Listing 4.13 to read a header line at a time
*/
/* Print each header line, with eol indicating the location
of CRLF at the end-of-line */
char *line = buffer;
char *eol = strstr (line, "\r\n");
size_t body_length = 0;
while (eol != NULL)
{
/* Null-terminate the line by replacing CRLF with \0 */
*eol = '\0';
printf ("HEADER LINE: %s\n", line);
/* Get the intended body length (in bytes) */
if (! strncmp (line, "Content-Length: ", 16))
{
char *len = strchr (line, ' ') + 1;
body_length = strtol (len, NULL, 10);
}
/* Move the line pointer to the next line */
line = eol + 2;
eol = strstr (line, "\r\n");
}
After Code Listing 4.14 establishes the Content-Length of the message (either request or response), this length can be compared with the length of the body that was already read. That is, the initial read from the socket received no more than 8 KB of data, which was the maximum size of the header. However, the body contents (particular for HTML data, images, and other objects returned as a response) are likely to exceed this 8 KB size limit. Consequently, an additional read() may be required to retrieve the rest of the body contents. Code Listing 4.15 completes the response processing by duplicating the body contents received so far and resizing it to read in the additional data. Note that line 12 will read from the socket into the space just after the existing body contents. 1
2
3
4
5
6
7
8
9
10
11
12
13 /* Code Listing 4.15:
Extending Code Listing 4.13 to read a header line at a time
*/
char *body = strdup (eoh + 4);
if (body_length > strlen (body)) // if false, all data received
{
/* Increase the body size and read additional data from the
socket; the number of bytes to request is the Content-Length
field minus the number of bytes already received */
body = realloc (body, body_length);
bytes = read (socketfd, body + strlen (body), body_length - strlen (body));
}
In Code Listings 4.13, 4.14, and 4.15, we have been implicitly assuming the data was HTML for simplicity. The response header would declare this with the Content-Type header. However, the same principle ideas would apply regardless of the type of data requested. For instance, if the client issues a GET request for /logo.png, the response would start with the same headers we have used, but the Content-Type would inform the client that the body contains image/png instead of text/html. Given that images can contain the null-byte, Code Listing 4.13 and Code Listing 4.15 would need to be modified to avoid the use of strlen(). However, the code shown here could be adapted to support binary data objects, such as images. 4.5.5. Persistent State with Cookies¶ Designing HTTP to be stateless worked well for its original purpose of sending and receiving documents. As the uses of web pages and the Internet have evolved, however, the lack of state information became a hindrance. Developers began to use HTTP as the foundation for web-based applications that required state persistence. As an example, consider a web-based email serice. The first request might allow a user to log into the system, then a second request would retrieve the messages in the user’s inbox. Additional requests would retrieve pages for composing new messages and sending them. Clearly, such an application design would benefit from storing persistent information on the server about the user. In modern web development, there are multiple options for data persistence. HTTP cookies are one of the oldest and most pervasive tools to accomplish this. A cookie is a short, text-based key-value pair that gets sent as an HTTP header field (similar to the Content-Length or Connection headers previously discussed). Code Listing 4.16 demonstrates one way to create a cookie in Javascript. 1
2
3
4
5
6
7
8
9 /* Code Listing 4.16:
Creating a new cookie in Javascript that expires in 15 minutes
*/
var date = new Date();
date.setTime(date.getTime() + 15 * 60 * 1000); // add 15 minutes
var newCookie = "username=julian;expires=" + date.toUTCString() +
";path=/;samesite=strict;secure";
document.cookie = newCookie;
The Javascript code in Code Listing 4.16 would run on the client side, causing the web browser to create a new cookie as the key-value pair username=julian. The rest of lines 7 and 8 control how the browser will use the cookie. The expires field indicates that the cookie is only valid for the next 15 minutes; it will be deleted after that time has passed. The path=/ indicates that this cookie will be sent along with any requests for the current domain name, regardless of the web site’s directory structure. The samesite=strict prevents the cookie from being sent to third-party web sites; that is, the cookie will not be sent to other domains, such as advertising networks. Lastly, the secure restricts the cookie to transfer over HTTPS and will prevent its transfer over standard HTTP. Line 9 adds the new cookie to the browser’s document.cookie value, which is the concatenated list of all cookies. (This line is unintuitive, as Javascript uses the assignment operator for this purpose, but the line is actually appending the value to an existing string.) Once the browser executes the code in Code Listing 4.16, future HTTPS requests that occur in the next 15 minutes will contain the HTTP header line Cookie: username=julian\r\n. Note that the header line does not contain information about the expiration date or the other fields, as these are only relevant to the browser. As an alternative, the server could also generate the cookie. The primary differences are that the HTTP header line would include all of the fields: Set-Cookie: username=julian;expires=Sat, 15 May 2021 16:00:00 GMT;
path=/;samesite=strict;secure
To add persistent state to the HTTP exchange, the server would use a database that mapped the cookie username=julian to information about the user. As such, the server-side code would be able to connect a new request to previous requests, creating the history needed for the application. One common technique, even without a specific user login mechanism, is to use a session cookie, such as session=182735927341. Session cookies persist until the web browser is closed, allowing servers an easy way to link requests from the same web browser as likely to be related. [1] While netcat is useful for exploring protocols, it sends all data in unencrypted form and cannot be used for any form of secure communication. [2] Using query strings with standard HTML files is pointless, as HTML is a static formatting language and cannot respond to input. Other server-side technologies, such as Java servlets, PHP, or Apache Server-Side Includes (SSI) are required to handle the query dynamically. « 4.4. The Socket Interface :: Contents :: 4.6. UDP Socket Programming: DNS » Contact Us License