W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007


From: Larry Masinter <LMM@acm.org>
Date: Mon, 25 Jun 2007 23:11:14 -0700
To: "'James M Snell'" <jasnell@gmail.com>, "'Henrik Nordstrom'" <henrik@henriknordstrom.net>
Cc: "'Lisa Dusseault'" <ldusseault@commerce.net>, <ietf-http-wg@w3.org>
Message-ID: <000701c7b7b8$cda904a0$68fb0de0$@org>

> The draft already talks about returning the modified entity, with an 200
> example carrying it..
> If the server do not want to return the modified entity then it can
> return a 204.

Don't make this optional. The server shouldn't send the modified
entity unless the client needs it, and the server has no way to
determine whether the client needs it.  And the client can ask
for it by doing a GET.

Behavior should be predictable, and the fewer options you have,
the better.

I'm not entirely convinced that there is a demand for single client
multiple server implementations of PATCH, or that it is viable
without a MTI content-type for patching instructions. 
And if prior out-of-band agreement is needed, then you might as
well just use POST with constructed URLs (http://site/path ->
http://site/PATCHER/path for example), and you'd avoid the
problem of expecting infrastructure that never heard of
PATCH to quickly implement its POST-like caching rules.

Received on Tuesday, 26 June 2007 06:11:21 UTC

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