Do Not Upgrade Your Rails Project to Ruby 2 Before You Read This(avi.io)
avi.io
Do Not Upgrade Your Rails Project to Ruby 2 Before You Read This
http://avi.io/blog/2013/12/17/do-not-upgrade-your-rails-project-to-ruby-2-before-you-read-this/
18 comments
The clickbait title is pretty obnoxious. I know that it is the current craze to style that way, but I can't help but imagine that a more helpful title would be something like: "Ruby 2 breaks existing projects by adding Accept-Encoding: gzip"...
How about "Test suites are awesome and help you find bugs during major upgrades"? I mean, this is basically your standard old "Regression tests helped us find a break in our software when performing a major upgrade!" story, rather than a "OMG, Ruby 2 will kick your dog and knock up your wife, avoid at all costs!!11" warning tale.
This is textbook clickbait. Yawn.
This is textbook clickbait. Yawn.
This appears to be documented[1] behavior for Ruby.
Here's a quote about the header string specifically:
"If initheader doesn't have the key 'accept-encoding', then a value of "gzip;q=1.0,deflate;q=0.6,identity;q=0.3" is used, so that gzip compression is used in preference to deflate compression, which is used in preference to no compression. Ruby doesn't have libraries to support the compress (Lempel-Ziv) compression, so that is not supported. The intent of this is to reduce bandwidth by default."
I'm not involved in Ruby / Rails development, but it's interesting to note that there was a pull request[2] on the Rails core about enabling gzip compression by default. It was ultimately decided best left up to the webserver and closed with the following quote:
"Rails should focus on being an MVC.
Enabling Gzip was an idea, but I think we now have enough arguments to not implement it ;)
IMO feature closed"
This looks like one of those good arguments. From what I can tell, this isn't a Rails problem, but a Ruby problem. I happen to agree that enabling gzip compression is good practice, but I don't think it should default to enabled at the application layer.
[1] - http://ruby-doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HT...
[2] - https://github.com/rails/rails/pull/7327
Here's a quote about the header string specifically:
"If initheader doesn't have the key 'accept-encoding', then a value of "gzip;q=1.0,deflate;q=0.6,identity;q=0.3" is used, so that gzip compression is used in preference to deflate compression, which is used in preference to no compression. Ruby doesn't have libraries to support the compress (Lempel-Ziv) compression, so that is not supported. The intent of this is to reduce bandwidth by default."
I'm not involved in Ruby / Rails development, but it's interesting to note that there was a pull request[2] on the Rails core about enabling gzip compression by default. It was ultimately decided best left up to the webserver and closed with the following quote:
"Rails should focus on being an MVC.
Enabling Gzip was an idea, but I think we now have enough arguments to not implement it ;)
IMO feature closed"
This looks like one of those good arguments. From what I can tell, this isn't a Rails problem, but a Ruby problem. I happen to agree that enabling gzip compression is good practice, but I don't think it should default to enabled at the application layer.
[1] - http://ruby-doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HT...
[2] - https://github.com/rails/rails/pull/7327
The pull request about Rails gzip compression talks about compressing http responses from Rails. While the blog post above, and the Ruby documentation of Net::HTTP, are talking about Ruby's new shiny default of compressing http requests (without care of the compressed response).
Other than including the words 'gzip compression' the two topics are very different.
Other than including the words 'gzip compression' the two topics are very different.
What does this have to do with Rails?
So, did you file a bug with Ruby?
That seems like an awkward default header, especially if it's not going to deflate it (which causes more issues such as needing the content-length header adjusted and checksums...) It just seems like a bad idea:(
I could not agree more. The combination of decisions seems even weirder.
1. default request header on by default 2. support for deflation off by default
WAT?
1. default request header on by default 2. support for deflation off by default
WAT?
A ridiculous number of sites use that header to determine whether or not they should provide content. Note they don't actually provide encoded content, they just won't provide the non-encoded content if you don't send that header. (I assume this is the reason for it; I have no inside knowledge.)
Can you provide an example of this? I've never run into an instance of this before.
IIRC http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd did in the past, though it no longer appears to. I know I've run into it in _many_ other places but it's been awhile and I no longer remember the various ones. I should also probably note that they were universally _not_ locations which you would generally be hitting programmatically.
I've been building a webcrawler that casts a pretty wide net and I've yet to run into it. I'm not just talking about API endpoints and stuff - I've never run into this doing general crawls of the web.
Same here, I have never encountered such a case
Or if you are actually going to perform an upgrade, consider a move to one of the more mature, stable, secure frameworks under Python, Perl or PHP.
Less Rails - less fails. Simple!
Less Rails - less fails. Simple!