W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: Updated Patch

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 22 Dec 2008 11:47:37 +0100
Message-ID: <494F7049.6010100@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT