5 ms·

Do Not Upgrade Your Rails Project to Ruby 2 Before You Read This

25 points by avitzurel 13y ago

jimktrains2 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      Can you provide an example of this? I've never run into an instance of this before.
      - avitzurel 13y ago
        Same here, I have never encountered such a case
      - mnarayan01 13y ago
        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 13y ago
        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.
veeti 13y ago
So, did you file a bug with Ruby?
static_typed 13y ago
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!
- orenmazor 13y ago
  hahahaha. good one.
- avitzurel 13y ago
  I'll consider it next time ;)
- tzaman 13y ago
  Less trolling would definitely help too.
- cmelbye 13y ago
  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?"
mnarayan01 13y ago
What does this have to do with Rails?
jwise0 13y ago
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 13y ago
  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 13y ago
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/HTTP.html#class-Net::HTTP-label-Compression http://ruby-doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HT... [2] - https://github.com/rails/rails/pull/7327 https://github.com/rails/rails/pull/7327
- kesor 13y ago
  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.

25 points by avitzurel 13y ago

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 13y ago
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 13y ago
  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 13y ago
    Can you provide an example of this? I've never run into an instance of this before.
    - avitzurel 13y ago
      Same here, I have never encountered such a case
    - mnarayan01 13y ago
      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 13y ago
        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.

veeti 13y ago

So, did you file a bug with Ruby?

static_typed 13y ago

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!

orenmazor 13y ago
hahahaha. good one.
avitzurel 13y ago
I'll consider it next time ;)
tzaman 13y ago
Less trolling would definitely help too.
cmelbye 13y ago
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?"

mnarayan01 13y ago

What does this have to do with Rails?

jwise0 13y ago

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 13y ago
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 13y ago

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/HTTP.html#class-Net::HTTP-label-Compression http://ruby-doc.org/stdlib-2.1.0/libdoc/net/http/rdoc/Net/HT... [2] - https://github.com/rails/rails/pull/7327 https://github.com/rails/rails/pull/7327

kesor 13y ago
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.