- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 2 Aug 2007 10:03:35 +0200
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Mark Baker <distobj@acm.org>, "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org
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: HRB5782
Received on Thursday, 2 August 2007 08:03:54 UTC