Even if you allow that PUT is not a wild goose chase, he is still making trivial patches, the first of which is not correct, and the second of which he states he did not verify was correct, even after being rejected the first time. So if we discount that he is demonstrating how to build a bad API, he's still demonstrating how to be a bad participant in the patching process.

I'm adhering as best I can to the (nearly completely undefined) development practices of the project I'm working on. My assumption is that upstream developers will continue to guide me through the testing and improving of my patch. Even in a loosely run project I would hope my patch would be applied to the development build for wider testing long before it's included in production.

I'm using Nginx now, and developing a RESTful API.

I was planning to use the HTTPDavModule (http://wiki.nginx.org/HttpDavModule) which adds the HTTP and WebDAV methods PUT, DELETE, MKCOL, COPY and MOVE.

Did you try this before? If its compatible with proxying, then it wouldn't be necessary to patch the server for HTTP PUT requests.

Nginx supports PUT and DELETE without the dav module. It however requires PUT requests include a Content-Length header and does not support Transfer-Encoding: chunked (although the chunkin module adds this support).

The problem I was wrestling with was specifically PUT requests with no entity body and therefore no Content-Length (or chunked transfer encoding).

I've tried to explain in other comments why asking our users to add a Content-Length: 0 to empty PUTs isn't feasible.

If your RESTful API supports PUTs without bodies, you'll need to either use my patch or ask your users to always include Content-Length: 0.