HTTP The Definitive Guide （Message)

报文组成： 起始行(start line)， 首部（header)， 主体(body)
请求报文格式：
<method> <request-url> <version>
<headers>

<entity-body>

响应报文格式：
<version> <status> <reason-phrase>
<headers>

<entity-body>

==========================================

version: HTTP/<major>.<minor>

Request Method:

GET Get a document from the server.
HEAD Get just the headers for a document from the server.
POST Send data to the server for processing.  - Has Message Body
PUT Store the body of the request on the server.  - Has Message Body
TRACE Trace the message through proxy servers to the server.
OPTIONS Determine what methods can operate on a server.
DELETE Remove a document from the server.

Status Code:
100-199 100-101 Informational

Status codes between 200 and 299 represent success. Codes between 300 and 399
indicate that the resource has been moved. Codes between 400 and 499 mean that
the client did something wrong in the request. Codes between 500 and 599 mean
something went awry on the server.


most common status codes

200 OK Success! Any requested data is in the response body
401 Unauthorized You need to enter a username and password.
404 Not Found The server cannot find a resource for the requested URL.

Header classifications
General headers
      Can appear in both request and response messages
Request headers
      Provide more information about the request
Response headers
      Provide more information about the response
Entity headers
      Describe body size and contents, or the resource itself
Extension headers
      New headers that are not defined in the specification

Header continuation lines
     Long header lines can be made more readable by breaking them into multiple lines,
preceding each extra line with at least one space or tab character.

HEAD method:
Using HEAD, you can:
• Find out about a resource (e.g., determine its type) without getting it.
• See if an object exists, by looking at the status code of the response.
• Test if the resource has been modified, by looking at the headers.

TRACE
When a client makes a request, that request may have to travel through firewalls,
proxies, gateways, or other applications. Each of these has the opportunity to modify
the original HTTP request. The TRACE method allows clients to see how its
request looks when it finally makes it to the server.

OPTIONS
The OPTIONS method asks the server to tell us about the various supported capabilities
of the web server.


Clients and 100 Continue
     If a client is sending an entity to a server and is willing to wait for a 100 Continue
response before it sends the entity, the client needs to send an Expect request header
(see Appendix C) with the value 100-continue. If the client is not sending an entity, it
shouldn’t send a 100-continue Expect header, because this will only confuse the
server into thinking that the client might be sending an entity.

Servers and 100 Continue
     If a server receives a request with the Expect header and 100-continue value, it should
respond with either the 100 Continue response or an error code (see Table 3-9). Servers
should never send a 100 Continue status code to clients that do not send the 100-
continue expectation.

Proxies and 100 Continue
     A proxy that receives from a client a request that contains the 100-continue expectation
needs to do a few things. If the proxy either knows that the next-hop server (discussed
in Chapter 6) is HTTP/1.1-compliant or does not know what version the
next-hop server is compliant with, it should forward the request with the Expect
header in it. If it knows that the next-hop server is compliant with a version of HTTP
earlier than 1.1, it should respond with the 417 Expectation Failed error.

300–399: Redirection Status Codes
       you may have noticed a bit of overlap between the 302, 303, and
307 status codes. There is some nuance to how these status codes are used, most of
which stems from differences in the ways that HTTP/1.0 and HTTP/1.1 applications
treat these status codes.
When an HTTP/1.0 client makes a POST request and receives a 302redirect status
code in response, it will follow the redirect URL in the Location header with a GET
request to that URL (instead of making a POST request, as it did in the original
request).
HTTP/1.0 servers expect HTTP/1.0 clients to do this—when an HTTP/1.0 server
sends a 302status code after receiving a POST request from an HTTP/1.0 client, the
server expects that client to follow the redirect with a GET request to the redirected
URL.
The confusion comes in with HTTP/1.1. The HTTP/1.1 specification uses the 303
status code to get this same behavior (servers send the 303 status code to redirect a
client’s POST request to be followed with a GET request).
To get around the confusion, the HTTP/1.1 specification says to use the 307 status
code in place of the 302status code for temporary redirects to HTTP/1.1 clients.
Servers can then save the 302 status code for use with HTTP/1.0 clients.
What this all boils down to is that servers need to check a client’s HTTP version to
properly select which redirect status code to send in a redirect response.

400–499: Client Error Status Codes
        Sometimes a client sends something that a server just can’t handle, such as a badly
formed request message or, most often, a request for a URL that does not exist.

500–599: Server Error Status Codes
        Sometimes a client sends a valid request, but the server itself has an error.


Conditional request headers

• Expect Allows a client to list server behaviors that it requires for a request
• If-Match Gets the document if the entity tag matches the current entity tag for the documenta
• a See Chapter 7 for more on entity tags. The tag is basically an identifier for a version of the resource.
• If-Modified-Since Restricts the request unless the resource has been modified since the specified date
• If-None-Match Gets the document if the entity tags supplied do not match those of the current document
• If-Range Allows a conditional request for a range of a document
• If-Unmodified-Since Restricts the request unless the resource has not been modified since the specified date
• Range Requests a specific range of a resource, if the server supports range requestsb

Negotiation headers

• Accept-Ranges The type of ranges that a server will accept for this resource
• Vary A list of other headers that the server looks at and that may cause the response to vary; i.e., a list of headers the server looks at to pick which is the best version of a resource to send the client

Response security headers

• Proxy-Authenticate A list of challenges for the client from the proxy
• Set-Cookie Not a true security header, but it has security implications; used to set a token on the client side that
• the server can use to identify the client
• Set-Cookie2 Similar to Set-Cookie, RFC 2965 Cookie definition; see “Version 1 (RFC 2965) Cookies” in Chapter 11
• WWW-Authenticate A list of challenges for the client from the server

Content headers

• Content-Basea The base URL for resolving relative URLs within the body
• Content-Encoding Any encoding that was performed on the body
• Content-Language The natural language that is best used to understand the body
• Content-Length The length or size of the body
• Content-Location Where the resource actually is located
• Content-MD5 An MD5 checksum of the body
• Content-Range The range of bytes that this entity represents from the entire resource
• Content-Type The type of object that this body is

Entity caching headers
        The general caching headers provide directives about how or when to cache. The
entity caching headers provide information about the entity being cached.

• ETag The entity tag associated with this entity
• Expires The date and time at which this entity will no longer be valid and will need to be fetched from the original source
• Last-Modified The last date and time when this entity changed