- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Fri, 21 May 2004 12:50:53 -0700
- To: Jamie Lokier <jamie@shareable.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
On May 21, 2004, at 5:05 AM, Jamie Lokier wrote: > Julian Reschke wrote: >>> The server SHOULD provide a MD5 hash of the content after the >>> delta >>> was applied. This allows the client to verify the success of the >>> operation. The PATCH method obviously MUST cause the ETag to >>> change. >>> So, if the server supports ETags, the server MUST return a strong >>> ETag for use in future client operations. If the server does not >>> support strong ETags, then the server MUST return the >>> Last-Modified >>> header instead. >> >> 1. 2. 3. > > 4. The PATCH method won't cause the ETag to change if the patched > entity is identical to the one before patching. Fixed. > >>> OPTIONS * presents a bit of a special case, as it does not >>> address a >>> resource, and does not always show all the server's features. In >>> responses to OPTIONS *, a server supporting this specification >>> SHOULD >>> include the PATCH method in the "Allow" header and SHOULD show the >>> union of all supported diff methods in the "Accept-Patch" header. >> >> This SHOULD level requirement in general can not be implemented using >> the Java servlet API; it's also very unclear how it actually helps the >> client in any way, as the supported delta formats may vary across >> resources. Please explain the rational. > > It also cannot be implemented in general over reverse-proxies which > forward requests to different servers depending on the URL. > OPTIONS * is a difficult problem; I don't really have a solution to it, nor do I know of any consensus on "the right thing" to do about it. The requirement is only a SHOULD, since obviously some implementations can't do this.
Received on Friday, 21 May 2004 15:51:28 UTC