Re: Updated Patch

Lisa Dusseault wrote:
>> I can't recall why we're making this requirement; it seems to copy a
>> requirement for PUT. However, for PUT, "applying an entity header" just
>> means storing it. What does it mean for PATCH? This introduces a
>> "must-understand" rule without knowing what "understand" precisely 
>> means...
> 
> This seems to have gotten broken unintentionally.  It used to read "The 
> server MUST NOT ignore any Content-* headers".  That's a much more 
> reasonable requirement, because the server can tell what headers are 
> Content-* headers while it can't tell what entity-headers are. And the 
> requirement to understand the Content-* headers means that the server 
> knows what to do with it which depends on : to save the Content-Type or 
> Content-Language as metadata, to confirm or ignore the Content-Length, etc.

Well, RFC 2616 says that any header that is not a request or general 
header is an entity header. And yes, this is not really true in practice.

An no, the entity header, thus the Content-* headers do *not* apply to 
the resource being patched, but to the payload. So when I use 
Content-Type: application/diff in a PATCH request, I do *not* want that 
to be set on the resource being patched :-).

>> Section 6., paragraph 1:
>> OLD:
>>
>>     The security considerations for PATCH are nearly identical to the
>>     security considerations for PUT.  In addition, one might be concerned
>>     that a document that is patched might be more likely to be corrupted,
>>     but that concern can be addressed through the use of mechanisms such
>>     as conditional requests using ETags and the If-Match request header.
>>
>> I don't think RFC2616 has any specific ones for PUT, so this is a bit
>> misleading...
> 
> I hope that the security considerations for PUT will shortly be updated :)

That may be the case (do you have something specific in mind?), but as 
long as the draft refers to RFC2616 some rephrasing seems to be in order 
:-).

  >> - I noticed a broken internal Section link; you may check all them,
>> optimally using xml2rfc to keep track of them.
> 
> There's an xml2rfc version of the doc.

Yes, but apparently not all internal links are marked up as such.

> ...

BR, Julian

Received on Monday, 22 December 2008 10:48:25 UTC