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

Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 2 Aug 2007 10:03:35 +0200
Message-Id: <0BB13BEE-163F-4F5A-B2A1-DC3BB3CCA00B@greenbytes.de>
Cc: Mark Baker <distobj@acm.org>, "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org
To: Roy T. Fielding <fielding@gbiv.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT