Am 01.08.2007 um 20:36 schrieb Roy T. Fielding: > We don't have that problem today with PATCH, AFAIK. There is no > reason not to define a 200 response to PATCH as being the same as > the representation that would have been received in a GET response > after the patch has been successfully applied. Remember, we aren't > forcing the server to return 200 -- the server can choose which > status is returned. Since we are defining anyway, I am wondering how this works with clients that are not interested in such a response body. The only way they could avoid retrieving the body is to close connection. I imagine as use case clients that edit/add ID tags on a web resource and perform a binary patch. Most certainly that will be protected by ETags and the client will not be interested in retrieving the quite large representation again. Is it worth considering a way for him to say so, or is closing the connection the appropriate behaviour? Imagine someone like flickr... It sounds like a nice job for a new "Expect" request header. Let's say we call this "patched-content": PATCH /resource/x HTTP/1.1 Host: www.example.com Expect: patched-content Content-Type: ... HTTP/1.1 417 Expectation failed ... <html><body>Sorry, we do not server content on a patch.</body></html> -- Stefan Eissing <green/>bytes GmbH Hafenweg 16 D-48155 Münster Germany Amtsgericht Münster: HRB5782Received on Thursday, 2 August 2007 08:03:54 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 September 2008 03:48:58 GMT