Opened 12 years ago

Closed 10 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 12 years ago by mnot@…

  • Component set to semantics
  • Milestone set to unassigned
  • version set to d00

comment:2 Changed 12 years ago by julian.reschke@…

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.

comment:3 Changed 11 years ago by mnot@…

  • Milestone changed from unassigned to 06

comment:4 Changed 11 years ago by julian.reschke@…

  • Milestone changed from 06 to unassigned

comment:5 Changed 10 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 10 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].

Note: See TracTickets for help on using tickets.