

Do Not Upgrade Your Rails Project to Ruby 2 Before You Read This - avitzurel
http://avi.io/blog/2013/12/17/do-not-upgrade-your-rails-project-to-ruby-2-before-you-read-this/

======
jwise0
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"...

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

------
randomdrake
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...](http://ruby-
doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HTTP.html#class-Net::HTTP-label-
Compression)

[2] -
[https://github.com/rails/rails/pull/7327](https://github.com/rails/rails/pull/7327)

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

------
mnarayan01
What does this have to do with Rails?

------
veeti
So, did you file a bug with Ruby?

------
jimktrains2
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:(

~~~
avitzurel
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?

~~~
mnarayan01
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.)

~~~
cheald
Can you provide an example of this? I've never run into an instance of this
before.

~~~
mnarayan01
IIRC
[http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd](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.

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

------
static_typed
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!

~~~
cmelbye
Maybe I'm alone on this, but I've never thought "I have to upgrade to a new
Ruby point version anyways, why not just rewrite everything in
Python/Perl/PHP(?) while I'm at it?"

