2. cnp3-ebook
3. protocols/http
4. English
5. Zen

55 ../../protocols/http.rst:188
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `3` indicate that the requested document is no longer available on the server. `301 Moved Permanently` indicates that the requested document is no longer available on this server. A `Location:` header containing the new URI of the requested document is inserted in the HTTP response. `304 Not Modified` is used in response to an HTTP request containing the `If-Modified-Since:` header. This status line is used by the server if the document stored on the server is not more recent than the date indicated in the `If-Modified-Since:` header. 577/10000 · 577
56 ../../protocols/http.rst:189
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `4` indicate that the server has detected an error in the HTTP request sent by the client. `400 Bad Request` indicates a syntax error in the HTTP request. `404 Not Found` indicates that the requested document does not exist on the server. 275/10000 · 275
57 ../../protocols/http.rst:190
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `5` indicate an error on the server. `500 Internal Server Error` indicates that the server could not process the request due to an error on the server itself. 195/10000 · 195
58 ../../protocols/http.rst:192
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In both HTTP requests and responses, the MIME document refers to a representation of the document with the MIME headers indicating the type of document and its size. 165/10000 · 165
59 ../../protocols/http.rst:194
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As an illustration of HTTP/1.0, the transcript below shows a HTTP request for `http://www.ietf.org <http://www.ietf.org>`_ and the corresponding HTTP response. The HTTP request was sent using the curl_ command line tool. The `User-Agent:` header line contains more information about this client software. There is no MIME document attached to this HTTP request, and it ends with a blank line. 392/10000 · 392
60 ../../protocols/http.rst:203
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The HTTP response indicates the version of the server software used with the modules included. The `Last-Modified:` header indicates that the requested document was modified about one week before the request. A HTML document (not shown) is attached to the response. Note the blank line between the header of the HTTP response and the attached MIME document. The `Server:` header line has been truncated in this output. 418/10000 · 418
61 ../../protocols/http.rst:216
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — HTTP was initially designed to share text documents. For this reason, and to ease the implementation of clients and servers, the designers of HTTP chose to open a TCP connection for each HTTP request. This implies that a client must open one TCP connection for each URI that it wants to retrieve from a server as illustrated on the figure below, showing HTTP 1.0 and the underlying TCP connection. For a web page containing only text documents this was a reasonable design choice as the client usually remains idle while the (human) user is reading the retrieved document. 572/10000 · 572
62 ../../protocols/http.rst:252
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, as the web evolved to support richer documents containing images, opening a TCP connection for each URI became a performance problem [Mogul1995]_. Indeed, besides its HTML part, a web page may include dozens of images or more. Forcing the client to open a TCP connection for each component of a web page has two important drawbacks. First, the client and the server must exchange packets to open and close a TCP connection as we will see later. This increases the network overhead and the total delay of completely retrieving all the components of a web page. Second, a large number of established TCP connections may be a performance bottleneck on servers. 666/10000 · 666
63 ../../protocols/http.rst:255
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This problem was solved by extending HTTP to support persistent TCP connections :rfc:`2616`. A persistent connection is a TCP connection over which a client may send several HTTP requests. This is illustrated in the figure below showing the persistent connection of HTTP 1.1. 275/10000 · 275
64 ../../protocols/http.rst:306
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To allow the clients and servers to control the utilization of these persistent TCP connections, HTTP 1.1 :rfc:`2616` defines several new HTTP headers: 151/10000 · 151
65 ../../protocols/http.rst:308
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `Connection:` header is used with the `Keep-Alive` argument by the client to indicate that it expects the underlying TCP connection to be persistent. When this header is used with the `Close` argument, it indicates that the entity that sent it will close the underlying TCP connection at the end of the HTTP response. 321/10000 · 321
66 ../../protocols/http.rst:309
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `Keep-Alive:` header is used by the server to inform the client about how it agrees to use the persistent connection. A typical `Keep-Alive:` contains two parameters: the maximum number of requests that the server agrees to serve on the underlying TCP connection and the timeout (in seconds) after which the server will close an idle connection 348/10000 · 348
67 ../../protocols/http.rst:311
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The example below shows the operation of HTTP/1.1 over a persistent TCP connection to retrieve three URIs stored on the same server. Once the connection has been established, the client sends its first request with the `Connection: Keep-Alive` header to request a persistent connection. 286/10000 · 286
68 ../../protocols/http.rst:321
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The server replies with the `Connection: Keep-Alive` header and indicates that it accepts a maximum of 100 HTTP requests over this connection and that it will close the connection if it remains idle for 15 seconds. 214/10000 · 214
69 ../../protocols/http.rst:336
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The client sends a second request for the style sheet of the retrieved web page. 80/10000 · 80
70 ../../protocols/http.rst:347
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The server replies with the requested style sheet and maintains the persistent connection. Note that the server only accepts 99 remaining HTTP requests over this persistent connection. 184/10000 · 184
71 ../../protocols/http.rst:362
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Then the client requested the web server's icon [#ffavicon]_. This server does not contain such an icon and thus replies with a `404` HTTP status. However, the underlying TCP connection is not closed immediately. 212/10000 · 212
72 ../../protocols/http.rst:383
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As illustrated above, a client can send several HTTP requests over the same persistent TCP connection. However, it is important to note that all of these HTTP requests are considered to be independent by the server. Each HTTP request must be self-contained. This implies that each request must include all the header lines that are required by the server to understand the request. The independence of these requests is one of the key design choices of HTTP. As a consequence of this design choice, when a server processes a HTTP request, it does not use any other information than what is contained in the request itself. This explains why the client adds its `User-Agent:` header in all of the HTTP requests that it sends over the persistent TCP connection. 759/10000 · 759
73 ../../protocols/http.rst:385
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, in practice, some servers want to provide content tuned for each user. For example, some servers can provide information in several languages. Other servers want to provide advertisements that are targeted to different types of users. To do this, servers need to maintain some information about the preferences of each user and use this information to produce content matching the user's preferences. HTTP contains several mechanisms to solve this problem. We discuss three of them below. 497/10000 · 497
74 ../../protocols/http.rst:387
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A first solution is to force the users to be authenticated. This was the solution used by `FTP` to control the files that each user could access. Initially, user names and passwords could be included inside URIs :rfc:`1738`. However, placing passwords in the clear in a potentially publicly visible URI is completely insecure and this usage has now been deprecated :rfc:`3986`. HTTP supports several extension headers :rfc:`2617` that can be used by a server to request the authentication of the client by providing his/her credentials. However, user names and passwords have not been popular on web servers as they force human users to remember one user name and one password per server. Remembering a password is acceptable when a user needs to access protected content, but users will not accept to remember a unique user name and password for each web sites that they visit. 878/10000 · 878