Re: Idempotent partial updates

On 28.02.2012 13:54, Adrien de Croy wrote:
> I wasn't talking so much about partial updates using PUT, but the
> general reliance on the concept of idempotence at all.
>
> Various features in HTTP, such as pipelining, recovering from closes
> etc rely on certain methods being idempotent.  I would propose one 
> can
> never assume any method is idempotent, since that is up to 
> server-side
> implementation.

It is required for cacheability assumptions on the response in absence 
of explicit "Cache-Control: public". Since almost no sites explicitly 
send "public" we can't exactly erase that property without causing a 
whole lot of pain to a lot of network administrators.

An HTTP bandwidth increase of between 20% and 50% on certain Tier-1 
network pipes is at stake and not something to play around with.

Intermediary admin already have to violate the specs to a certain 
degree, ignoring no-cache to reduce bandwidth costs wrongly imposed by 
broken server libraries which insist on sending no-cache and no-store on 
static content.

>
> Whether in practise PUT is usually actually idempotent or not I don't
> have any information.
>
> But my feeling is there is a disconnect between HTTP and those making
> websites in this regard.
>

IME the disconnect is happening around about the library/framework/SDK 
layer. The documentation for those is spares on HTTP details, and some 
of their defaults are actually causing violations of the HTTP specs. 
This thread on PUT with partials being a case in point. PHP insistence 
on sending prohibitive cache-controls by default has also led to many 
broken web apps. ASP has similar problems. the litany of implementation 
compliance bugs and side effects is _long_.

AYJ

Received on Tuesday, 28 February 2012 01:56:39 UTC