W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 21 May 2004 13:05:51 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org, Lisa Dusseault <lisa@osafoundation.org>
Message-ID: <20040521120551.GA27507@mail.shareable.org>

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.

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

-- Jamie
Received on Friday, 21 May 2004 08:06:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC