5 ms·

As I currently work in the K-12 educational software industry this is something I would be extremely sensitive to. The sheer number of creaky, old proxy server

As I currently work in the K-12 educational software industry this is something I would be extremely sensitive to. The sheer number of creaky, old proxy servers out there that we have to contend with is mind boggling. I'm sure others have to deal with this to but I suspect that the education market is one where people will run into surprises and most likely won't realize what the issue is right away. As the sibling post pointed out there is way to change the http method used but I suspect most people won't do this or know about this and this is a really really hard thing to QA for.

tptacek 15y ago
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.
- ryanto 15y ago
  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.
- apike 15y ago
  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.
  - lparry 15y ago
    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.
    - justincormack 15y ago
      That's not true xmlhttprequest should support all methods but there are some quirks eg see http://www.mnot.net/javascript/xmlhttprequest/ http://www.mnot.net/javascript/xmlhttprequest/ to test though that does not cover PATCH.
      - lparry 15y ago
        I stand corrected, I hadn't thought about js requests
  - SystemOut 15y ago
    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.
- saurik 15y ago
  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. :(
  - hythloday 15y ago
    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.
    - saurik 15y ago
      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.

tptacek 15y ago

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.

ryanto 15y ago
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.
apike 15y ago
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.
- lparry 15y ago
  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.
  - justincormack 15y ago
    That's not true xmlhttprequest should support all methods but there are some quirks eg see http://www.mnot.net/javascript/xmlhttprequest/ http://www.mnot.net/javascript/xmlhttprequest/ to test though that does not cover PATCH.
    - lparry 15y ago
      I stand corrected, I hadn't thought about js requests
- SystemOut 15y ago
  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.
saurik 15y ago
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. :(
- hythloday 15y ago
  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.
  - saurik 15y ago
    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.