I have a hard time believing that Rails programmers will use resource routing and not understand _method. It's pretty fundamental to the way the framework works. Are you a Rails dev? If not, just know: for the most part, we're talking about different flavors of HTTP POST.
At the time of reading your comment it is light gray. I am not sure why people are downvoting you... _method is a pretty important part of the rails routing and solves a lot of the proxy/server problems that people are mentioning.
In fact, I would argue that things like put/patch/_method are what make Rails so great. Rails makes a lot of strong opinions (put, whoops no, patch!), but then at then end of the day always gives you a way (_method) to deal with any issues where their opinions may not work in your current architecture. This pattern appears throughout the framework and is one of the reasons I really enjoy Rails.
If everyone is going to be using _method, then there is no advantage to using a specific method at all. If I tell people "I have an API: you use PATCH to use it", but in fact if you do that it no longer works behind a ton of proxies, you either don't use it before shipping or it's too late.
Imagine if this was "we are using a new non-HTTP network protocol, and the answer to "how will you get it through proxies" is not "we tested it: it works" but instead "we have a way to tunnel it over HTTP"... that is a non-answer that undermines the entire purpose of having a new protocol, and restating it with pointlessly denegrating statements about people who don't know about the tunneling system doesn't help: it just makes the feature that much more questionable. :(
I don't understand. Either PATCH (and PUT and DELETE) work on (say) K-12 networks, or they don't. If PATCH doesn't work on K-12 networks, you have to tunnel; Rails does that with "_method", and every competent Rails programmer knows about "_method". If PATCH does work on K-12 networks, well, Rails supports it, and would in fact prefer you use it.
What's the complaint here? Rails can't do anything about shitty proxy software. It's there, and Rails works around it.
If PATCH does not work there, then you always need to tunnel. You do not know if the client is a K-12 network by User-Agent. If you always need to tunnel, you may as well define the protocol to be "you can use POST with _method now to say PATCH".
My "complaint" (I am not certain why you are using that term, as all I said was that I had a "disappointment" with the article announcing the feature) is that time was spent discussing "does my web server support it" (you can always change your webserver) as opposed to "will my client support it" (which is an interesting and important question).
(Also, it should be noted that Rails doesn't work around the "shitty proxy software": it provides a way to allow the client code to work around it, but it doesn't itself work around it. If there really are networks out there that don't route PATCH--which I didn't even believe in my original post, but was corrected with this K-12 failure--then you, the developer, are going to end up just never using PATCH.)
It may amuse you to know that your "new non-HTTP protocol" is basically describing SPDY, Google's new alternative-to-HTTP protocol, which is live and works in Chrome and e.g. any netty-powered webserver.
Look the counterfactual: any protocol (including HTTP...or TCP...or IP...) has "no advantages" unless both endpoints can understand it and the network can transmit it at the most appropriate layer. Until then, it requires tunnelling. That was definitely the case for the first rollout of TCP/IP, or HTTP.
It definitely doesn't imply that it shouldn't be done--the only thing that it implies is that it's harder work for the adopters until it has a critical mass of mind share and then it becomes harder for the non-adopters. If the alternative to that is no, or only centralized, improvements to protocols, I'll take the breakages.
I specifically thought of SPDY when I used that example; in fact, that's what makes it such a great example: SPDY asked themselves this question, and had a really great answer for it (specifically, that HTTP is used first, and only if the server opts in to using SPDY does it upgrade to a faster protocol, saving that information for later use).
The saddest part here is that I agree with you: I like that Rails decided to do this, and for the very reasons you describe. However, I expressed disappointment that this announcement/article decided to ask "will my web server support this" and didn't bother to ask "will the client be able to route to me with this".
Remember: I myself believed it would work, and even provided multiple reasons in my post for why it would. However, it would have been nice to see these points brought up in the article. If my version of nginx doesn't support it, I'll just upgrade, but if I'm honestly concerned about support, I'm going to care if I can even trust a PATCH to my client code.
The concern isn't simply that there will be Rails programmers in K-12 that don't know how to override an HTTP method. The concern is that when K-12 users are using Rails 4 apps (that may or may not be K-12 specific) they may fail in bizarre ways that are hard to troubleshoot.
It's not an issue because web browsers only support GET and POST. Rails works around this by including a hidden field "_method" which contains the method the server should treat the request as.
This was more my point that I didn't get across correctly. When apps fail due to weird proxy issues they are incredibly hard to figure out and almost impossible to QA correctly for without a huge budget. And if this causes it, sure the Rails programmer might know how to solve it once they actually realize why it's failing. The why is the harder part.
