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 Methods
(Page 4 of 4)
"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.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|