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 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.