Re: PATCH draft

Cyrus Daboo wrote:
> - In the example in Section 2.1 there is a Content-MD5 header in the 
> response. What does that refer to? The actual response body is empty.

Right. This contradicts the definition of Content-MD5 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.15>), so 
it probably would be good to remove it.

That being said: I think the HTTPbis definition of Content-MD5 should be 
changed so that it can be sent with a 204 as updated metadata. (new issue?)

> - Security: PATCH will likely require the server to use a lot more CPU 
> than a straight PUT. If someone were to define an "active" patch format 
> (e.g. one with a repeat or loop capability), then a malicious client 
> could use that as a denial-of-service vector. Can we add text like the 
> following to Security Considerations:
> 
>    Servers MUST take adequate precautions to ensure that malicious
>    clients cannot consume excessive server resources (e.g., CPU, disk I/O)
>    through the client's use of PATCH.

+1, except I don't think we need BCP14 language here. It's sufficient to 
make implementors aware of the problem.

> Isn't there a response code for the server to indicate it is giving up 
> processing because the client request has consumed too much e.g., CPU?

I don't think so... Do we need one for interop?

> - There should be some statement in the document along the lines of:
> 
>    Clients need to make a smart choice on when it is applicable to use
>    PATCH rather than PUT. For example, if the patch document size is
>    larger than the size of the new resource data that would be used in a
>    PUT, then it probably makes sense to use PUT instead of PATCH.


I do not disagree with the statement, but I'm also not sure it *needs* 
to be stated (so +-0 on that).

BR, Julian

Received on Friday, 30 January 2009 16:39:59 UTC