- 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>
> 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. Larry
Received on Tuesday, 26 June 2007 06:11:21 UTC