29/07/09 11:27:37 (13 years ago)

Resolve #27: fix definition of idempotent

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

    r655 r657  
    690690<iref item="Idempotent Methods" primary="true"/>
    692    Methods can also have the property of "idempotence" in that (aside
    693    from error or expiration issues) the side-effects of N &gt; 0 identical
    694    requests is the same as for a single request. The methods GET, HEAD,
    695    PUT and DELETE share this property. Also, the methods OPTIONS and
    696    TRACE &SHOULD-NOT;  have side effects, and so are inherently idempotent.
    697 </t>
    698 <t>
    699    However, it is possible that a sequence of several requests is non-idempotent,
    700    even if all of the methods executed in that sequence are
    701    idempotent. (A sequence is idempotent if a single execution of the
    702    entire sequence always yields a result that is not changed by a
    703    reexecution of all, or part, of that sequence.) For example, a
    704    sequence is non-idempotent if its result depends on a value that is
    705    later modified in the same sequence.
    706 </t>
    707 <t>
    708    A sequence that never has side effects is idempotent, by definition
    709    (provided that no concurrent operations are being executed on the
    710    same set of resources).
     692   Methods can also have the property of "idempotence" in that, aside
     693   from error or expiration issues, the intended effect of multiple
     694   identical requests is the same as for a single request.
     695   The methods PUT, DELETE, and all safe methods are idempotent.
     696   It is important to note that idempotence refers only to changes
     697   requested by the client: a server is free to change its state due
     698   to multiple requests for the purpose of tracking those requests,
     699   versioning of results, etc.
Note: See TracChangeset for help on using the changeset viewer.