W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Idempotent partial updates

From: Mike Kelly <mikekelly321@gmail.com>
Date: Thu, 1 Mar 2012 01:04:02 +0000
Message-ID: <CANqiZJYwss-4g+uj1_beAnEfYcj+GqET81Zp2n++FT7YZaV5ig@mail.gmail.com>
To: Henrik Nordström <henrik@henriknordstrom.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
2012/3/1 Henrik Nordström <henrik@henriknordstrom.net>:
> ons 2012-02-29 klockan 23:52 +0000 skrev Mike Kelly:
>> Upgrading PUT so it is less specific about replacement wouldn't result
>> in this breakage. Clients don't make requests to servers arbitrarily,
>> they make them according to whatever application they are fulfilling.
>> i.e. if an application is operating on the basis that PUT requests to
>> its resources are replacements, then HTTP relaxing the semantics of
>> PUT to permit partials would not create breakage.
> That's besides the point. To be able to extend PUT like this within
> HTTP/1.x it needs to be possible to send the extended request form
> arbitrarily without causing breakage. A condition that partial PUT may
> only be sent if it's known prior to sending the request that the
> receiving server is somehow magically capable of accepting this form of
> PUT without causing breakage is not acceptable within HTTP/1.x.
> For a change in PUT syntax to be acceptable within HTTP/1.1 you MUST be
> able to send such PUT requests to any server without any prior knowledge
> of the capabilities of that server and know that the server will process
> the request with an acceptable outcome. Storing the partial
> representation as the sole representation of the resource is not
> regarded as an acceptable outcome so this is not acceptable extension of
> PUT within HTTP/1.x.

Ok, so it sounds to me like you are saying that what would happen in
reality is besides the point because there is a rule governing the
design of PUT in HTTP/1.x which must not be broken. Is there any
evidence of that rule producing some benefit to the web?

Received on Thursday, 1 March 2012 01:04:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC