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

Re: PATCH Draft

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 26 Jun 2007 00:26:27 +0200
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: James M Snell <jasnell@gmail.com>, ietf-http-wg@w3.org, Lisa Dusseault <lisa@osafoundation.org>
Message-Id: <1182810387.4708.66.camel@henriknordstrom.net>
mån 2007-06-25 klockan 22:27 +0200 skrev Stefan Eissing:

> Personally, I think this is not helpful. PATCH cannot require servers  
> to support such a format. For every format it is trivial to think of  
> an application where it does not make sense.

Sure, but for interoperability it helps a lot if there is at least one
text and one binary format that most clients can expect to be supported
on most servers, therefore one or two recommendations on formats to use
helps a lot.

This do not mean that every server MUST support those formats, or that
there SHOULD NOT be any other formats supported. Only that there is an
established recommendation on what formats to use unless there is strong
reasons not to, in order to make interoperability reasonable.

> >   * Should it be possible to create new resources with PATCH
> Non-issue in my mind: up to the application. See above.

I disagree. Part of this should be in the protocol. Most importanly if
it should be possible for the client to ask the server that a new
resource should be created based on another "template" resource and a

> >   * Should it be required to use If-Match and If-Unmodified-Since
> >     on PATCH.
> Definitely not. Let's say subversion wants to use PATCH, using the  
> good old diff format on text files. It is definitely counter- 
> productive to require it to fail on changed ETags when it clearly  
> does not want to.

I'd say it should be a SHOULD requirement unless the delta format in
question has it's own conflict resolution.

> On the other hand, one can think of applications using PATCH to save  
> bandwidth. Using some simple binary patch format. Such applications  
> will make heavy use of If-Match headers and rightly so.

Needs to be clearly mentioned, or I'm afraid there will be lots of
implementations which overlooks this.

> Replace: "The server MUST NOT create a new resource with the contents  
> of the request body, although it MAY (depending on the delta  
> encoding) apply the request body to an empty resource."
> By: "If the server accepts PATCH on a non-existing resource is up to  
> the server implementation."
> Reason: there may be applications where it makes sense, others might   
> strictly forbid it.

Why? There is already the PUT method for creating entities. Unless we
talk about creating a resource from a template + delta ofcourse..

> Idea: Only describe difference of PATCH responses to PUT responses


> Idea: should "Accept-Patch" header also appear in responses to PATCH?

Yes, I'd say so. The modified resource do not need to support further
PATCH modifications, depending on the application.


Received on Monday, 25 June 2007 22:26:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC