Re: PATCH Draft

Ah, I was waiting for this and had something prepared. Many thanks  
for James for reviving the draft!

Am 25.06.2007 um 22:10 schrieb James M Snell:
> There are some issues that definitely need to be worked out.
>
>   * Should there be a single minimum recommended diff format
>     for binary/character based resources.  I know that this has
>     been controversial in the past and I personally don't have
>     an opinion on it.  I know that Lisa would prefer for there
>     to be at least one minimum recommendation

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.

>   * Should it be possible to create new resources with PATCH

Non-issue in my mind: up to the application. See above.

>   * 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.

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.

>
> I'm sure there are other issues :-)
>
> Comments? Concerns?

Comments and personal opinions about patch-07:

based on: http://www.greenbytes.de/tech/webdav/draft-dusseault-http- 
patch-07.html

2.1 PATCH Method

replace "delta encoding" by something not using "encoding". "patch  
document type" maybe...

Strike: "and MUST include sufficient information to allow the server  
to recreate the changes necessary to convert the original version of  
the resource into the desired version."
Reason: obvious

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.

Replace: "origin server" by "server"

Replace whole paragraph: "Collisions from ...."
By:
"PATCH documents should carry enough context information that allow  
the server to correctly apply the change or fail the PATCH. While  
applications may differ in their requirments here, the general idea  
is that PATCH documents can be applied to a start document in any  
order and either produce a failure or the very same end document.

Changes that require strict ordering SHOULD be secured by using ETags  
and If-Match headers."

Drop: "Servers should provide strong ETags..."

Idea: "maybe replace the hyptothetical example by a diff/patch text one?


2.2 PATCH Response

Idea: Only describe difference of PATCH responses to PUT responses
Idea: should "Accept-Patch" header also appear in responses to PATCH?

2.3 Advertising Support

Idea: clarify what advertising "Accept-PATCH" headers in GET  
responses mean?

"If Accept-PATCH appears on a response to a GET request, the client  
can expect the server to support PATCH with the listed document types  
on this particular resource."

3. Delta Encodings

Rename to: "PATCH Document Types"

Strike: everything about character encoding of PATCH documents
Strike: "Structure-based delta...."


Not Found:

- Some words about safety, idempotent aspect of PATCH?

Cheers,

Stefan
--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782

Received on Monday, 25 June 2007 20:28:12 UTC