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

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.