Re: Idempotent partial updates

On Wed, Feb 29, 2012 at 7:00 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Feb 29, 2012, at 10:54 AM, Julian Reschke wrote:
>
>> On 2012-02-29 19:50, Roy T. Fielding wrote:
>>> On Feb 29, 2012, at 9:46 AM, Carsten Bormann wrote:
>>>> On Feb 28, 2012, at 20:54, Roy T. Fielding wrote:
>>>>> On Feb 28, 2012, at 9:31 AM, Carsten Bormann wrote:
>>>>>
>>>>>> I'm not sure we are communicating.
>>>>>>
>>>>>> In the web-as-deployed, partial updates often use the PUT method.
>>>>>
>>>>> In the Web as defined, standardized, and deployed, those partial
>>>>> updates using the PUT method are not interoperable with standard
>>>>> HTTP/1.x servers.  [...]
>>>>> Any software that uses Content-Range in PUT requests is BROKEN.
>>>>
>>>> Thanks, that was part of the input I was looking for.
>>>>
>>>> For the other part of discussion we are having (PATCH vs. idempotence), it would be useful to know what specifically broke when people started using PUT for partial updates.  In particular, it would be good to know if the same breakage occurs with an idempotent version of PATCH.
>>>
>>> When a server that implemented PUT prior to the introduction of
>>> Content-Range received a partial content body that included such
>>> a range, they would replace the entire resource representation with
>>> the partial body.  That is how PUT was defined to work.  That's how
>>> it was implemented long before ranges existed.  Hence, the introduction
>>> of partial PUT would only be possible with a strong coupling between
>>> client and origin server implementations, which violates the design
>>> of the HTTP.
>>>
>>> By design, HTTP method semantics cannot be changed in an incompatible
>>> way without a major version change in the protocol.  Since the WG
>>> refused to bump the protocol version, partial PUT was forbidden.
>>> PATCH was delegated to the WebDAV group to standardize.
>>
>> Yes.
>>
>> But I *think* there's some terminology confusion here.
>>
>> When Mike, who brought this up, talks about partial updates with PUT, he's referring to a PUT request *without* Content-Range, replacing *parts* of the identified resource; and leaving the remainder alone.
>
> Which is even less interoperable than the Content-Range hack because
> now the site cannot even detect it.
>
> As I've told Mike a dozen times already, what he describes is contrary
> to the definition of PUT.  It is therefore invalid HTTP.  Whether it is
> valid in other protocols is not our problem.

It can't be unambiguously contrary to 2616, otherwise why would there
have been any need to clarify the semantics via HTTPbis?

Sites can detect whether it is partial vs replace the same way they
distinguish between the intent of a POST requests - it depends on the
resource in question.

Received on Wednesday, 29 February 2012 19:10:14 UTC