Your article is about how you hacked nginx for your specific need (eventually fix it if it finally merge to 0.8) but not a "complete noob guide".
That being said, nice fix !
Judging from my understanding of the article, you are using Ubuntu. Please, please, please don't ever teach "complete noobs" installing anything this way. I won't insist on full course of backporting with apt-get source, hacking on debian/* and doing dpkg-buildpackage, but even silly `sudo chown -R $USER /usr/local && make install` is more appropriate than Slackware-ish `sudo make install`. And, while far from being perfect, checkinstall(1), is easy to use and should work fairly well.
I had to manage several Debian GNU/Linux-based systems with ton of software installed this way, and it was... well, quite painful. Package management is there for a reason.
You can know all of those things and more about a RESTful web service without reading a line of documentation. So I would personally consider the distinctions between HTTP verbs very useful and quite underutilized.
The UNIX filesystem is another example where distinctions between seemingly arbitrary terms helps a user know more about a system without knowing details about a specific implementation: /home is for user data, /etc for configuration, /var can probably be mounted non-executable, /usr/local mirrors /usr, etc.
Despite a wide range of variation amongst implementations, someone familiar with these distinctions can navigate fairly comfortably on a wide range of operating systems and distributions.
On the other hand, let's pretend my patch is worthless. I would hope that doesn't lessen the usefulness of my post. My attempt was not to enforce some pedantic standards compliance but rather introduce developers to how to diagnose problems and come to solutions.
You could build an Ajax button easily. You couldn't build a basic submit button to do it (supposedly--on my phone so no cross browser testing).
Your point is taken that browsers don't really speak HTTP. There are plenty of clients that do, generally for programmers working with APIs. These are at issue.
Not via a regular form (let alone link)
> What buttons do I press in firefox to send PUT?
It wouldn't be a button, it would be a form@method
Or possibly he is referring to actually validating XHTML, since errors often reported by the validator do not matter as far as rendering goes. If this is the case, I personally disagree: validate your damn HTML.
With proper development process (with development->staging->production cycle), and fair tests coverage, there shouldn't be any problems with strict XHTML validation. Except for human laziness (I'm guilty too, of course) and lack of easy-to-use "here, install this toy, fill in this five-line config and deploy with just one command" tools.
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.
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.
I'd like to see a diagram of that state machine!
1. The pragmatic one - our current web server doesn't require hacks like that, so there's lots of existing code out of our control that would break.
2. The pedantic one - at Urban Airship we try to offer as standards compliant a RESTful HTTP API as possible. Asking our users to work around shortcomings in our system is something we avoid as much as possible.
If the HTTP standard allows it, we probably need to support it (or degrade in a standards compliant way) because someone will try to use it.
I'm not criticizing the article itself; it was a nice beginner guide to making quick changes to an existing C project. My only criticism is that the first step when considering whether to make a change to a code base is to fully evaluate whether that change is appropriate, if it is fixing the problem in the right place. Perhaps the author did this and the article simply failed to mention it.