Comments on draft-dusseault-http-patch-00

...see 
<http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-00.txt>


In general, I think this addresses a real performance issue, and I'd 
imagine that existing WebDAV clients and servers will soon take 
advantage of it.

Comments:

 >   2.  DeltaV extends WebDAV to do versioning.  In versioning
 >       environments, a large number of files may be updated with very
 >       small changes.  For example, a programmer may change the name of
 >       a function used in a hundred source files.  Versioning
 >       applications typically send deltas or 'diffs' to the server to
 >       modify these files, however DetaV does not yet have this
 >       functionality.

Note: it may make sense to talk to the Subversion guys about how they 
are handling this case.

 >   3.  The SIMPLE WG is devising a way to store and modify configuration
 >       information. The biggest feature missing from HTTP is the ability
 >       to modify information in a very lightweight manner, so that the
 >       client that decides to change its presence state from "free" to
 >       "busy" doesn't have to upload a large document. This can be
 >       accomplished through changes to a HTTP resource as well.

In general, this can also be done by choosing a greater granularity in 
authorable resources (URIs). That being said, changing part of the 
contents of an authorable resource is of course a useful feature in any 
case.

 >   This specification defines a new HTTP 1.1 method for patches [HTTP].
 >   A new method is necessary to improve interoperability and prevent
 >   errors. The PUT method is already defined to overwrite a resource
 >   with a complete new body, and MUST NOT be reused to do partial
 >   changes. Otherwise, proxies and caches and even clients and servers
 >   may get confused as to the result of the operation.

Note: an alternative would be to use the HTTP Extension Framework 
(RFC2774), use M-PUT and define a mandatory range extension.

 >   PATCH bodies are not cachable.  A cache MAY mark the resource
 >   identified in the Request-URI as stale if it sees a successful
 >   response to the PATCH request.

I think we need to talk about the cacheability of responses (in this 
case, MUST not). We may also need to define whether PATCH is a "safe" or
"idempotent" message (RFC2616, sectiom 9.1). I'd say that PATCH is
neither safe nor idempotent (I think it may be idempotent for a few
specific patch formats, but in general probably not).

 >   The PATCH request MUST have a body.  It MUST include the Content-Type
 >   header with a value indicating what the body type is.  It MUST be a

...what the mime type of the message body is...

 >   format that has the semantics of defining a change to an existing
 >   document (such as gdiff or vcdiff).   The PATCH request MUST also use
 >   one of the standard HTTP/1.1 mechanisms that let the server know when
 >   the request body is done. The PATCH request body length MUST NOT be
 >   indicated only by closing the connection when the body is complete,
 >   because an incomplete PATCH body could conceivably corrupt the target
 >   resource.

How would that work? If a client sends PATCH and closes the connection 
before reading the result, this wouldn't work anyway. Please elaborate.

 >   The PATCH request MUST only be used in a context which ensures that
 >   only one user may apply a patch at a time.  There are two reliable
 >   ways to do this. The first way is to find out the resource ETag at
 >   the time the body is downloaded, and use that Etag in the PATCH
 >   request to make sure the resource is still unchanged.  The second way
 >   to use WebDAV LOCK/UNLOCK [WEBDAV] to reserve the file (first LOCK,
 >   then GET, then PATCH, then UNLOCK).  PATCH collisions from multiple
 >   users are more dangerous than PUT collisions, because a PATCH that is
 >   not operating from a known base point may corrupt the resource.
 >   Therefore, if neither strong ETags nor LOCKS are available from the
 >   server, the client MUST use If-Last-Modified as a less-reliable
 >   safeguard.

In this case (:-), I'd argue for a stronger requirement (MUST only work 
for resources that support strong etags).

 >   The PATCH method can return the following errors. Please note that
 >   the notation "DAV:foobar" is merely short form for expressing "the
 >   'foobar' element in the 'DAV:' namespace".  It has meaning only in
 >   English, not on the wire.  Also note that the string error codes are
 >   not meant to be displayed but instead as machine parsable known error
 >   codes (thus there is no language code).

<default-comment>Use RFC3253 terminology, thus name the precondition,
not the error condition</default-comment>

 >   Set of defined delta formats

General comment: there should be only one (or two) MUST requirements, 
one for sending updates to arbitrary ranges in the resource, one for 
truncating the resource to a specific length. It would be optimal if 
both can be done using the same format.

 >   When the OPTIONS request addresses a specific modifiable resource,
 >   the Patch header in the response indicates which delta formats may be
 >   used for this specific resource.  When an OPTIONS request addresses
 >   the server as a whole (Request-URI = "*") the Delta header in the
 >   response indicates the union of all delta formats supported by the
 >   server.

Not implementable using the Java servlet API.


Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 20 November 2003 16:25:39 UTC