• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

To authors of HFS

 
janne s
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

i'm preparing for SCWCD exam. I'm reading HFS for exam... i browsed the forum and read posts on idempotent and non-idempotent methods..later i was confused which one i shud consider correct...thought lets ask authors of the book...

I think..

POST - NON-IDEMPOTENT

GET,HEAD,DELETE,TRACE,PUT - IDEMPOTENT

CONNECT,OPTIONS - I DON'T KNOW

Pls tell me which one r idempotent and which r non-idempotent.
what shud i consider for exam?

Thank you in advance
jaya
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only POST, PUT and DELETE don't need to be idempotent.

Cheers,
Jose
 
Ritu varada
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think POST and CONNECT are not idempotent but everything else is.
 
janne s
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Ritu
 
Ion Gherasim
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Jose. Ritu, which is your reason?
 
Ritu varada
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I take that back.Jose is correct! Sorry about that!
 
janne s
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

hmm...this confusion always prevails..
so Jose is right but then in HFS they gave
only POST as non-idempotent.

you say POST,PUT,DELETE r non-idempotent.

in the exam if i get a question to choose non-idempotent method
which one shud i choose?


jaya
 
Ritu varada
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason why I said PUT was idempotent was becuase of the illustration used by one of the websites to point to the difference between PUT and POST. It siad that POST was like an INSERT while PUT was like an update and hence PUT could be considered idempotent. I was replying with that thought in mind. Now, when you cross-examined me, I went back to the spec and it says what Jose said. I agree with the spec 100% .So, I agree with Jose. Sorry if I caused any confusion!
 
Ritu varada
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For that , I have one answer for you. When in doubt, ALWAYS, read the spec!!!
 
janne s
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

According to specs :

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested possibly unsafe action is being requested

9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.


so i think PUT and CONNECT - NON-IDEMPOTENT.


HTTP1.1


If i'm wrong pls explain...

Thanks in advance
Jaya
 
Karen Philip
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

So, can we say this:

idempotent: GET, HEAD
non-idempotent: PUT, POST, DELETE, OPTIONS, TRACE, CONNECT

TIA
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Karen Philip:
Hi,

So, can we say this:

idempotent: GET, HEAD
non-idempotent: PUT, POST, DELETE, OPTIONS, TRACE, CONNECT

TIA


An idempotent request is a request which, if performed more than once doesn't have different effects, as correctly statated above:


Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.



Let's think at the PUT method: it places a file somewhere on the server. If you perform the same PUT request, the result will be the same: the same file at the same location on the server, therefore PUT can be considered idempotent.

On the other hand, if you post a request which has as consequence the debit of a credit card, the effect is not the same if the same request is performed once or more than once. This is the concept of a non-idempotent request. From latin: idem (same) potent(power)
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to Servlet 2.4 spec (page 235):
doPut method:
"This method does not need to be either safe or idempotent."

According to HTTP/1.1 spec:
"The methods GET, HEAD, PUT and DELETE share this property [idempotence]."

How are these spec compatible? Is the doPut method non-idempotent but the PUT operation idempotent?

I had used the Servlet spec, but now I'm confused.

BTW Karen, you are not right according to any of these spec.
 
Jose Esteban
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Marco Tedone:


Let's think at the PUT method: it places a file somewhere on the server. If you perform the same PUT request, the result will be the same: the same file at the same location on the server, therefore PUT can be considered idempotent.


Then, why does the Servlet 2.4 spec (page 235) say about the doPut method:
"This method does not need to be either safe or idempotent."?

Could you consider that, if you repeat a PUT operation, the time stamp of the file you PUT changes, so the result is not the same as the original and therefore, the method could be considered as non-idempotent.
 
janne s
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can anyone explain whether CONNECT method is idempotent or not?
 
Vishnu Prakash
Ranch Hand
Posts: 1026
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IDEMPOTENT ==> GET, HEAD, PUT, DELETE, OPTIONS, TRACE

NON-IDEMPOTENT ==> POST

CONNECT
Specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling

Source
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic