Methods
Let's talk in more detail about the some of the basic HTTP methods, listed earlier in Table 3-1. Note that not all methods are implemented by every server. To be compliant with HTTP Version 1.1, a server need implement only the GET and HEAD methods for its resources.
Even when servers do implement all of these methods, the methods most likely have restricted uses. For example, servers that support DELETE or PUT (described later in this section) would not want just anyone to be able to delete or store resources. These restrictions generally are set up in the server's configuration, so they vary from site to site and from server to server.
Safe Methods
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.
By no action, we mean that nothing will happen on the server as a result of the HTTP request. For example, consider when you are shopping online at Joe's Hardware and you click on the "submit purchase" button. Clicking on the button submits a POST request (discussed later) with your credit card information, and an action is performed on the server on your behalf. In this case, the action is your credit card being charged for your purchase.
There is no guarantee that a safe method won't cause an action to be performed (in practice, that is up to the web developers). Safe methods are meant to allow HTTP application developers to let users know when an unsafe method that may cause some action to be performed is being used. In our Joe's Hardware example, your web browser may pop up a warning message letting you know that you are making a request with an unsafe method and that, as a result, something might happen on the server (e.g., your credit card being charged).
GET
GET is the most common method. It usually is used to ask a server to send a resource. HTTP/1.1 requires servers to implement this method. Screenshot 3-7 shows an example of a client making an HTTP request with the GET method.
(Screenshot 3-7.)
HEAD
The HEAD method behaves exactly like the GET method, but the server returns only the headers in the response. No entity body is ever returned. 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.
Server developers must ensure that the headers returned are exactly those that a GET request would return. The HEAD method also is required for HTTP/1.1 compliance. Screenshot 3-8 shows the HEAD method in action.
(Screenshot 3-8.)
PUT
The PUT method writes documents to a server, in the inverse of the way that GET reads documents from a server. Some publishing systems let you create web pages and install them directly on a web server using PUT (see Screenshot 3-9).
(Screenshot 3-9.)
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.
Because PUT allows you to change content, many web servers require you to log in with a password before you can perform a PUT. You can read more about password authentication in Chapter 12.
POST
The POST method was designed to send input data to the server. In practice, it is often used to support HTML forms. The data from a filled-in form typically is sent to the server, which then marshals it off to where it needs to go (e.g., to a server gateway program, which then processes it). Screenshot 3-10 shows a client making an HTTP request-sending form data to a server-with the POST method.
POST is used to send data to a server. PUT is used to deposit data into a resource on the server (e.g., a file).
(Screenshot 3-10.)
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.
A TRACE request initiates a "loopback" diagnostic at the destination server. The server at the final leg of the trip bounces back a TRACE response, with the virgin request message it received in the body of its response. A client can then see how, or if, its original message was munged or modified along the request/response chain of any intervening HTTP applications (see Screenshot 3-11).
(Screenshot 3-11.)
The TRACE method is used primarily for diagnostics; i.e., verifying that requests are going through the request/response chain as intended. It's also a good tool for seeing the effects of proxies and other applications on your requests.
As good as TRACE is for diagnostics, it does have the drawback of assuming that intervening applications will treat different types of requests (different methods-GET, HEAD, POST, etc.) the same. Many HTTP applications do different things depending on the method-for example, a proxy might pass a POST request directly to the server but attempt to send a GET request to another HTTP application (such as a web cache). TRACE does not provide a mechanism to distinguish methods. Generally, intervening applications make the call as to how they process a TRACE request.
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.
OPTIONS
The OPTIONS method asks the server to tell us about the various supported capabilities of the web server. You can ask a server about what methods it supports in general or for particular resources. (Some servers may support particular operations only on particular kinds of objects).
This provides a means for client applications to determine how best to access various resources without actually having to access them. Screenshot 3-12 shows a request scenario using the OPTIONS method.
(Screenshot 3-12.)
DELETE
The DELETE method does just what you would think-it asks the server to delete the resources specified by the request URL. However, the client application is not guaranteed that the delete is carried out. This is because the HTTP specification allows the server to override the request without telling the client. Screenshot 3-13 shows an example of the DELETE method.
(Screenshot 3-13.)
Extension Methods
HTTP was designed to be field-extensible, so new features wouldn't cause older software to fail. Extension methods are methods that are not defined in the HTTP/1.1 specification. They provide developers with a means of extending the capabilities of the HTTP services their servers implement on the resources that the servers manage.Some common examples of extension methods are listed in Table 3-5. These methods are all part of the WebDAV HTTP extension (see Chapter 19) that helps support publishing of web content to web servers over HTTP.
Table 3-5. Example web publishing extension methods | |
| Method | Description |
| LOCK | Allows a user to "lock" a resource-for example, you could lock a resource while you are editing it to prevent others from editing it at the same time |
| MKCOL | Allows a user to create a resource |
| COPY | Facilitates copying resources on a server |
| MOVE | Moves a resource on a server |
It's important to note that not all extension methods are defined in a formal specification. 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.
In these cases, it is best to be tolerant of extension methods. 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. Otherwise, they should respond with a 501 Not Implemented status code. Dealing with extension methods (and HTTP extensions in general) is best done with the old rule, "be conservative in what you send, be liberal in what you accept."