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

42 ../../protocols/http.rst:164
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Server:` header indicates the version of the web server that has generated the HTTP response. Some servers provide information about their software release and optional modules that they use. For security reasons, some system administrators disable these headers to avoid revealing too much information about their server to potential attackers. 350/10000 · 350
43 ../../protocols/http.rst:165
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Date:` header indicates when the HTTP response has been produced by the server. 84/10000 · 84
44 ../../protocols/http.rst:166
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Last-Modified:` header indicates the date and time of the last modification of the document attached to the HTTP response. 127/10000 · 127
45 ../../protocols/http.rst:168
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Similarly, the following header lines can only appear inside HTTP requests sent by a client: 92/10000 · 92
46 ../../protocols/http.rst:170
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `User-Agent:` header provides information about the client that has generated the HTTP request. Some servers analyze this header line and return different headers and sometimes different documents for different user agents. 227/10000 · 227
47 ../../protocols/http.rst:171
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `If-Modified-Since:` header is followed by a date. It enables clients to cache in memory or on disk recent or most frequently used documents. When a client needs to request a URI from a server, it first checks whether the document is already in its cache. If it is, the client sends an HTTP request with the `If-Modified-Since:` header indicating the date of the cached document. The server will only return the document attached to the HTTP response if it is newer than the version stored in the client's cache. 516/10000 · 516
48 ../../protocols/http.rst:172
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Referrer:` header is followed by a URI. It indicates the URI of the document that the client visited before sending this HTTP request. Thanks to this header, the server can know the URI of the document containing the hyperlink followed by the client, if any. This information is very useful to measure the impact of advertisements containing hyperlinks placed on websites. 377/10000 · 377
49 ../../protocols/http.rst:173
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Host:` header contains the fully qualified domain name of the URI being requested. 87/10000 · 87
50 ../../protocols/http.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The importance of the `Host:` header line 41/10000 · 41
51 ../../protocols/http.rst:177
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first version of HTTP did not include the `Host:` header line. This was a severe limitation for web hosting companies. For example consider a web hosting company that wants to serve both `web.example.com` and `www.example.net` on the same physical server. Both web sites contain a `/index.html` document. When a client sends a request for either `http://web.example.com/index.html` or `http://www.example.net/index.html`, the HTTP 1.0 request contains the following line : 476/10000 · 476
52 ../../protocols/http.rst:183
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — By parsing this line, a server cannot determine which `index.html` file is requested. Thanks to the `Host:` header line, the server knows whether the request is for `http://web.example.com/index.html` or `http://www.dummy.net/index.html`. Without the `Host:` header, this is impossible. The `Host:` header line allowed web hosting companies to develop their business by supporting a large number of independent web servers on the same physical server. 451/10000 · 451
53 ../../protocols/http.rst:185
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The status line of the HTTP response begins with the version of HTTP used by the server (usually `HTTP/1.0` defined in :rfc:`1945` or `HTTP/1.1` defined in :rfc:`2616`) followed by a three digit status code and additional information in English. HTTP status codes have a similar structure as the reply codes used by SMTP: 321/10000 · 321
54 ../../protocols/http.rst:187
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — All status codes starting with digit `2` indicate a valid response. `200 Ok` indicates that the HTTP request was successfully processed by the server and that the response is valid. 181/10000 · 181
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