clarify PUT semantics

[julian.reschke@…]

There's a permathread about PUT-for-partial-update.

We should clarify that PUT can be more than "store this payload verbatim", but that the final state should not depend on the previous state of the resource (except when by design; such when doing versioning...)

[julian.reschke@…]

I believe this can be closed as fixed as per [1158].

[fielding@…]

Yes, fixed in [1158]. The relevant paragraph added is

An origin server SHOULD reject any PUT request that contains a Content-Range header field, since it might be misinterpreted as partial content (or might be partial content that is being mistakenly PUT as a full representation). Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789]).