- From: Julian Reschke <julian.reschke@gmx.de>
- Date: 2008年12月22日 11:47:37 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <494F7049.6010100@gmx.de>
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