ch03: HTTP Messages
Last updated
Last updated
How messages flow
The three parts of HTTP messages(start line, headers, and entity body)
The different parts of HTTP request and response messages
The various functions(methods) that request messages support
The various status codes that are returned with response messages
What the various HTTP headers do
HTTP uses the terms inbound and outbound to describe transactional direction:
HTTP messages flow like rivers. All messages flow, downstream, regardless of whether they are request messages or response messages. The sender of any message is upstream of the receiver:
Here's the format for a request message:
Here's the format for a response message:
The start line for a request message says what to do. The start line for a response message says what happended.
2.2.1 Request line
Request line contains a method, a request URL and HTTP version.
2.2.2 Response line
Response line contains the HTTP version, a numeric status code and a textual reason phrase.
2.2.3 Methods
Common HTTP methods:
Method | Description | Message body? |
GET | Get a document from the server. | No |
HEAD | Get just the headers for a document from the server. | No |
POST | Send data to the server for processing. | Yes |
PUT | Store the body of the request on the server. | Yes |
TRACE | Trace the message through proxy servers to the server. | No |
OPTIONS | Determine what methods can operate on a server. | No |
DELETE | Remove a document from the server. | No |
Not all servers implement all seven of the methods. HTTP was designed to be easily extensible, other servers may implement their own request methods in addition to these, called extension methods.
2.2.4 Status codes
Status code classes:
Overrall range | Defined range | Category |
100-199 | 100-101 | Informational |
200-299 | 200-206 | Successful |
300-399 | 300-305 | Redirection |
400-499 | 400-415 | Client error |
500-599 | 500-505 | Server error |
2.2.5 Version numbers
The version number indicates the highest version of HTTP that an application supports.
Note that version numbers are not treated as fractional numbers. Each number in the version is treated as a sepatate number. So, when comparing HTTP versions, each number must be compared separately in order to determine which is the higher version. For example, HTTP /2.22 is a higher version than HTTP/2.3, because 22 is a larger number than 3.
HTTP header fields add additional information to request and response messages.
2.3.1 Header classfications
The HTTP specification defines several header fields. Applications also are free to invent their own home-brewed headeres. HTTP headers are classified into:
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.
ESxtension headers
New headers that are not defined in the specification.
Common header examples:
Header example | Description |
Date: Tue, 3 Oct 1997 02:16:03 GMT | The date the server generated the response |
Content-length: 15040 | The entity body contains 15040 bytes of data |
Content-type: image/gif | The entity body is a GIF image |
Accept: image/gif, image/jpec, text/html | The client accepts GIF and JPEG images and HTML |
2.3.2 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:
Optional. Entity bodies are the payload of HTTP messages. They are the things that HTTP was designed to transport.
A far simpler protocol:
To be compliant with HTTP Version 1.1, a server need implement only the GET and HEAD methods for its resources.
HTTP defines a set of methods that are called safe methods. The GET and HEAD methods are said to be safe, meaning that no action should occur as a result of an HTTP request that uses either the GET or HEAD method.
GET is the most common method. It usually is used to ask a server to send a resource. HTTP/1.1 requires to implement this method:
The HEAD method behaves esxactly like the GET method, but the server returns only the headers in the response. This allows a client to inspect the headers for a resource without having to actually get the resource. 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.
The PUT method writes documents to a server:
The semantics of the PUT method are for the server to take the body of the request and either use it to create a new document named by the requested URL or, if that URL already exists, use the body to replace it.
The POST method was designed to send input data to the server. In practice, it is often used to support HTML forms:
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:
The TRACE method is used primarily for diagnostics.
No entity body can be sent with a TRACE request. The entity body of the TRACE response contains, verbatim, the request that the responding server received.
The OPTIONS method asks the server to tell us about the various supported capabilitites of the web server:
The DELETE method asks the server to delete the resources specified by the request URL. The HTTP specification allows the server to override the request without telling the client:
If you define an extension method, it's likely not to be understood by most HTTP applications. Likewise, it's possible that your HTTP applications could run into extension methods being used by other applications that it does not understand.
Proxies should try to relay messages with unknown methods through to downstream servers if they are capable of doing that without breaking end-to-end behavior.
Status code | Reason phrase | Meaning |
100 | Continue | Indicates that an initial part of the request was received and the client should continue. After sending this, the server must respond after receiving the request. |
101 | Switching Protocols | Indicates that the server is changing protocols, as specified by the client, to one listed in the Upgrade header. |
4.1.1 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 Except request header with the value 100-continue.
A client application should really use 100-continue only to avoid sending a server a large entity that the server will not be able to handle or use.
Clients that send an Except header for 100-continue should not wait forever for the server to send a 100 Continue response. After some timeout, the client should just send the entity.
4.1.2 Servers and 100 Continue
When receiving the Expect header and 100-continue value, the server should respond with either 100 Continue response or an error code.
Status code | Reason phrase | Meaning |
200 | OK | Request is okay. |
201 | Created | For requests that create server objects(PUT). The entity body of the response should contain the various URLs for referencing the created resource, with the Localtion header cantaining the most specific reference. |
202 | Accepted | The request was accepted, but the server has not yet performed any action with it. There are no guarantees that the server will complete the request; this just means that the request looked valid when accepted. |
203 | Non-Authoritative Information | |
204 | No Content | |
205 | Reset Content | Another code primarily for browsers. Tells the browser to clear any HTML form elements on the current page. |
206 | Partial Content | A partial or range request was successful. |
The redirection status codes either tell clients to use alternate locations for the resources they're interested in or provide an alternate response instead of the content:
If-Modified-Since:
Status code | Reason phrase |
300 | Multiple Choices |
301 | Moved Permanently |
302 | Found |
303 | See Other |
304 | Not Modified |
305 | Use Proxy |
306 | (Unused) |
307 | Temporary Redirect |
Status code | Reason phrase |
400 | Bad Request |
401 | Unauthorized |
402 | Payment Required |
403 | Forbidden |
404 | Not Found |
405 | Method Not Allowed |
406 | Not Acceptable |
407 | Proxy Authentication Required |
408 | Request Timeout |
409 | Conflict |
410 | Gone |
411 | Length Required |
412 | Precondition Failed |
413 | Request Entity Too Large |
414 | Request URI Too Long |
415 | Unsupported Media Type |
416 | Requested Range Not Statisfiable |
417 | Exception Failed |
Status code | Reason phrase |
500 | Internal Server Error |
501 | Not Implemented |
502 | Bad Gateway |
503 | Service Unavailable |
504 | Gateway Timeout |
505 | HTTP Version Not Supported |
Headers and methods work together to determine what clients and servers do.
General headers
These are generic headers used by both clients and servers.
Request headers
Are specific to request messages, providing extra information to servers.
Response headers
Provide information to the client.
Entity headers
Deal with the entity body.
Extension headers
HTTP programs need to tolerate and forward extension headers, even if they don't know what the headers mean.
Header | Description |
Connection | Allows clients and servers to specify options about the request/response connection |
Date | Provides a date and time stamp telling when the message was created |
MIME-Version | Gives the version of MIME that the sender is using |
Trailer | Lists the sest of headers that are in the trailer of a message encoded with the chunked transfer encoding |
Transfer-Encoding | Tells the receiver what encoding was performed on the message in order for it to be transported safely |
Upgrade | Gives a new version or protocol that the sendesr would like to "upgrade" to using |
Via | Shows what intermediaries(proxies, gateways) the message has gone through |
Cache-Control | Used to pass caching directions along with the message |
Pragma | Another way to pass directions along with the message, though not specific to caching |
Header | Description |
Client-IP | Provides the IP address of the machine on which the client is running |
From | Provides the email address of the client's user |
Host | Gives the hostname and port of the server to which the request is being sent |
Referer | Provides the URL of the document that contains the current request URI |
User-Agent | Tells the server the name of the application making the request |
Accept headers give the client a way to tell servers their preferences and capabilities.
Header | Description |
Accept | Tells the server what media types are okay to send |
Accept-Charset | Tells the server what charsets are okay to send |
Accept-Encoding | Tells the server what encodings are okay to send |
Accept-Language | Tells the server what languages are okay to send |
TE | Tells the server what extension transfer codings are okay to use |
Header | Description |
Age | How old the response is |
Public | A list of request methods the server supports for its resources |
Server | The name and version of the server's application software |
Header | Description |
Allow | Lists the reqeust methods that can be performed on this entity |
Location | Tells the client where the entity really is located; used in direction the receiver to a location for the resource |
Messages consist of three parts: start line describing the message, a block of headers containing attributes, and an optional body containing data:
