HTTP Message Methods - Part 2 of Chapter 3 from HTTP: The Definitive Guide (3/4) | WebReference

HTTP Message Methods - Part 2 of Chapter 3 from HTTP: The Definitive Guide (3/4)

To page 1To page 2current pageTo page 4
[previous] [next]

HTTP: The Definitive Guide, Chapter 3: HTTP Messages

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 Figure 3-11).

TRACE example
Figure 3-11. TRACE example

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. Figure 3-12 shows a request scenario using the OPTIONS method.

OPTIONS example
Figure 3-12. OPTIONS example


To page 1To page 2current pageTo page 4
[previous] [next]

Created: January 21, 2003
Revised: January 21, 2003

URL: https://webreference.com/programming/http/chap3/2/3.html