Opened 15 years ago
Closed 14 years ago
#27 closed editorial (fixed)
Idempotency
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | unassigned |
Component: | p2-semantics | Severity: | Active WG Document |
Keywords: | Cc: |
Description
It *appears* that RFC3253 changes the idempotency of PUT; is this allowed? RFC3253 doesn't update or obsolete 2616...
I can see a situation where a 3253-naive client decides to retry a timed-out PUT (after all, it's idempotent) and gets some side effects it didn't bargain for.
Change History (6)
comment:1 Changed 15 years ago by mnot@…
- Component set to semantics
- Milestone set to unassigned
- version set to d00
comment:2 Changed 15 years ago by julian.reschke@…
comment:3 Changed 14 years ago by mnot@…
- Milestone changed from unassigned to 06
comment:4 Changed 14 years ago by julian.reschke@…
- Milestone changed from 06 to unassigned
comment:5 Changed 14 years ago by mnot@…
- Priority set to normal
- Severity set to Active WG Document
- Summary changed from PUT Idempotency to Idempotency
- Type changed from design to editorial
comment:6 Changed 14 years ago by fielding@…
- Resolution set to fixed
- Status changed from new to closed
Replaced definition of idempotent with:
Methods can also have the property of "idempotence" in that, aside from error or expiration issues, the intended effect of multiple identical requests is the same as for a single request. The methods PUT, DELETE, and all safe methods are idempotent. It is important to note that idempotence refers only to changes requested by the client: a server is free to change its state due to multiple requests for the purpose of tracking those requests, versioning of results, etc.
in [657].
Discussed during the Prague meeting, see <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>: "Loosen definition of Idempotency as per Roy." -- See <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: Just ignore the definition of idempotent in RFC 2616. Anything specified in HTTP that defines how the server shall implement the semantics of an interface method is wrong, by definition. What matters is the effect on the interface as expected by the client, not what actually happens on the server to implement that effect.