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

AltStyle によって変換されたページ (->オリジナル) /