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

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