* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #27 (closed editorial: fixed)

Opened 9 years ago

Last modified 7 years ago


Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: unassigned
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/13f8f5c91d2a2ecbf43cb27e25914e3b@mnot.net


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

comment:1 Changed 9 years ago by mnot@pobox.com

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

comment:2 Changed 9 years ago by julian.reschke@greenbytes.de

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 8 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 06

comment:4 Changed 7 years ago by julian.reschke@gmx.de

  • Milestone changed from 06 to unassigned

comment:5 Changed 7 years ago by mnot@pobox.com

  • Priority set to normal
  • Type changed from design to editorial
  • Severity set to Active WG Document
  • Summary changed from PUT Idempotency to Idempotency

comment:6 Changed 7 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to fixed

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.