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

Re: PATCH Draft

From: James M Snell <jasnell@gmail.com>
Date: Wed, 04 Jul 2007 15:04:49 -0700
Message-ID: <468C1981.8020306@gmail.com>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Mark Baker <distobj@acm.org>, ietf-http-wg@w3.org

Lisa Dusseault wrote:
> [snip]
>> "The server MUST NOT create a new resource with the contents of the
>> request body"
>> Why not?  I don't see the problem.
> This is to require that the server not treat the PATCH like a PUT.  If
> there's a way to *apply* the patch to an empty body that might be fine,
> but the server should not save the delta algorithm as the resource body.
> If that's what the client wanted, it would do a PUT.

Yes. However, that is different than creating a new resource as the
result of applying a patch.  I think we need to be clear that it is ok
for the application of the patch to result in the creation of a resource
but, as you say, the server should not save the payload of the patch
request as the content of that new resource.

>> "Therefore, the client MUST verify that it is applying the delta
>> encoding to a known entity by first acquiring the strong ETag [...]"
>> I don't see why this is required.  Of course, if the client wants the
>> guarantees provided by strong etags, it can get them.  But why does
>> that matter to a protocol specification?  Suggest removal of that
>> paragraph.
> Why remove it?  What's the harm in making this requirement that clients
> behave properly?

Well, this requirement is predicated on the idea that the resource being
patched already exists.  If we allow the application of the patch to
result in the creation of a new resource, then it obviously cannot rely
on the use of strong etags.  I would suggest making this a SHOULD rather
than a MUST.

>> I suggest the use of 422 instead of 400 in the "malformed delta
>> encoding" case of sec 2.2.2.
> What's 422?

422 Unprocessable Entity from RFC2518.

   The 422 (Unprocessable Entity) status code means the server
   understands the content type of the request entity (hence a
   415(Unsupported Media Type) status code is inappropriate), and the
   syntax of the request entity is correct (thus a 400 (Bad Request)
   status code is inappropriate) but was unable to process the contained
   instructions.  For example, this error condition may occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous XML instructions.

The malformed delta encoding response assumes that the syntax of the
delta encoding is incorrect, which would make a 400 response
appropriate.  According to the text of 422, the syntax of the request is
assumed to be correct but still cannot be applied for whatever reason.

>> Sec 2.3 seems to over specify a few things.  For example, the Allow
>> response header isn't required to list "all the allowed methods" so
>> there's no need for "MUST" there.  I think that all you really need in
>> this section is the definition of the Accept-Patch header.
> The benefit of this requirement is so that clients can count on the
> Allow header for at least this case.  What's the harm of this requirement?

I don't see the harm in having it, but I also don't see any harm in
making it a SHOULD.  The presence of an Accept-Patch header in an
OPTIONS, GET, or HEAD response for a given resource will likely be
enough of a clue that the server supports the PATCH method for that

- James
Received on Wednesday, 4 July 2007 22:04:56 UTC

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