Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)                      9  TCP/IP Hypertext Transfer Protocol (HTTP)                           9  HTTP Messages, Message Formats, Methods and Status Codes

HTTP Generic Message Format 1 2 3 HTTP Response Message Format

Request Line

The generic start line that begins all HTTP messages is called a request line in request messages. Its has a three-fold purpose: to indicate the command or action that the client wants performed; to specify a resource upon which the action should be taken; and to indicate to the server what version of HTTP the client is using. The formal syntax for the request line is:

<METHOD> <request-uri> <HTTP-VERSION>

The method is simply the type of action that the client wants the server to take; it is always specified in upper case letters. There are eight standard methods defined in HTTP/1.1, of which three are widely used: GET, HEAD and POST. They are called “methods” rather than “commands” because the HTTP standard uses terminology from object-oriented programming. I explain this and also describe the methods themselves in the topic describing HTTP methods.

The request URI is the uniform resource identifier of the resource to which the request applies. While URIs can theoretically refer to either uniform resource locators (URLs) or uniform resource names (URNs), at the present time a URI is almost always an HTTP URL that follows the standard syntax rules of Web URLs.

Interestingly, the exact form of the URL used in the HTTP request line usually differs from that used in HTML documents or entered by users. This is because some of the information in a full URL is used to control HTTP itself. It is needed as part of the communication between the user and the HTTP client, but not in the request from the client to the server. The standard method of specifying a resource in a request is to include the path and file name in the request line (as well as any optional query information) while specifying the host in the special Host header that must be used in HTTP/1.1 requests.

For example, suppose the user enters a URL such as this:

http://www.myfavoritewebsite.com:8080/chatware/chatroom.php

We obviously don't need to send the “http:” to the server. The client would take the remaining information and split it so the URI was specified as “/chatware/chatroom.php” and the Host line would contain “www.myfavoritewebsite.com:8080”. Thus, the start of the request would look like this:

GET /chatware/chatroom.php HTTP/1.1
Host: www.myfavoritewebsite.com:8080

The exception to this rule is when a request is being made to a proxy server. In that case, the request is made using the full URL in its original form, so that it can be processed by the proxy just as the original client did. The request would be:

GET http://www.myfavoritewebsite.com:8080/chatware/chatroom.php HTTP/1.1

Finally, there is one special case where a single asterisk can be used instead of a real URL. This is for the OPTIONS method, which does not require the specification of a resource. (Nominally, the asterisk means the method refers to the server itself.)

The HTTP-VERSION element tells the server what version the client is using so the server knows how to interpret the request, and what to send and not to send the client in its response. For example, a server receiving a request from a client using versions 0.9 or 1.0 will assume that a transitory connection is being used rather than a persistent one, and will avoid using version 1.1 headers in its reply. The version token is sent in upper case as “HTTP/0.9”, “HTTP/1.0” or “HTTP/1.1”—just the way I've been doing throughout my discussion of the protocol.

HTTP Generic Message Format 1 2 3 HTTP Response Message Format