- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 25 Jun 2007 22:54:34 -0700
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: Lisa Dusseault <ldusseault@commerce.net>, ietf-http-wg@w3.org
Henrik Nordstrom wrote: > [snip] >> That should be fine. I wonder if it's worth the extra variation to >> allow the server to carry the entire modified entry. In some cases >> that would remove the whole point of supporting PATCH (allowing >> authoring of large files without constant uploading and downloading >> of entire file) so returning the body at least has to be optional. > > 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. Yep. Returning the complete entity body is optional in the draft and is likely only going to be useful when using structural deltas where things like MD5 hashes are inadequate for determining the success of the delta. > > The only question is if there is a need to have the server return status > messages on a successful PATCH other than the entity itself, or the > actual resulting diff if some server-side processing was done. If 200 > returns the modified entity then what to use if the server do not want > to return the modified entity but instead need to return status messages > about the successful PATCH operation or perhaps a diff? Good point. We would need some way of signaling that the returned entity is not the modified entity but itself a delta. Will have to think about that a bit more. > > For as long as 200 returns the modified entity there is no reason not to > allow it to be cached. > Agreed. >> Accept is a request header. I assumed that it would be viewed in bad >> taste to use it as a response header. It might also in the long run >> be confusing -- the server might accept certain diff formats for >> PATCH, but accept other inputs for other purposes. > > Agreed. > > But a more expressive name than Accept-<method> should probably be used > then. If not there is a risk for a name collision if/when other Accept-X > headers is added or new methods with similar names.. Hmm... I'm absolutely terrible at these kinds of discussions mainly because I tend not to care what the heck we call it as long as it does the job ;-). - James
Received on Tuesday, 26 June 2007 05:54:40 UTC