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 Response Message Format 1 2 3 4 HTTP Status Code Format, Status Codes and Reason Phrases

"Safe" and Idempotent Method Categorizations

As we've seen above, methods vary greatly in the type of behavior they cause the server to take. The HTTP standard defines two characteristics that can be used to differentiate methods based on the impact they have on a server:

• “Safe” Methods: These are methods that an administrator of a server can feel reasonably comfortable permitting a client to send because they are very unlikely to have any negative “side-effects”. The methods usually put into this category are GET, HEAD, OPTIONS and TRACE. The methods that cause data to be accepted by the server for processing, or lead to changes on the server, are deemed “unsafe”: POST, PUT, and DELETE. (The fact that they are “unsafe” doesn't mean a server never allows them, just that they require more care and detail in handling than the others.)
  
  
• Idempotent Methods: Woah, 10-dollar word time. J A method is said to be idempotent if repeating the same method request numerous times causes the exact same results as if the method were issued only once. For example, if you load a Web page in your browser, and then type the same URL in again, you get the same result, at least most of the time. In general, all of the methods in HTTP have this property inherently except one: POST.

The POST method is not idempotent because each instance of a POST request causes the receiving server to process the data in the request's body. Submitting a POST request two or more times can often lead to undesirable results. The classic example is hitting the “submit” button on a form more than once, which can lead to annoyances such as a duplicate message on an Internet forum, or even a double order at an online store.

There are also situations where a method that is normally idempotent may not be. A GET request for a simple document is idempotent, but a GET for a script can change files on the server and therefore is not idempotent. Similarly, a sequence of idempotent methods can be non-idempotent. For example, consider a situation where a PUT request is followed by a GET for the same resource. This sequence is non-idempotent because the second request depends on the results of the first.

The significance of non-idempotence is that clients must handle such requests or sequences specially. The client must keep track of them, and make sure that they are filled in order and only once. The HTTP standard also specifies that non-idempotent methods should not be pipelined, to avoid problems if an HTTP session is unexpectedly terminated. For example, if two POST requests were pipelined and the server got hung up handling them, the client would need to reissue them but might not know how many of the originals had been successfully processed.

HTTP Response Message Format 1 2 3 4 HTTP Status Code Format, Status Codes and Reason Phrases